Re: [Xenomai-help] Bad EIP kernel-Oops

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 2407 bytes --]

Nils Kemper wrote:
> Hi,
> I want to use Xenomai, but I get (sometimes, but everytime the same)
> kernel-Oops just by running xeno-test:
> 
> [..]
> Xenomai: stopping native API services.
> I-pipe: Domain Xenomai unregistered.
> Xenomai: hal/x86 stopped.
> Xenomai: real-time nucleus unloaded.
>  Unable to handle kernel NULL pointer dereference at virtual address 00000000
>  printing eip:
>  00000000
>  *pde = 00000000
>  Oops: 0000 [#1]
>  PREEMPT
>  Modules linked in: netconsole 8139too crc32 ipv6 nfs lockd sunrpc
> intel_agp ehci_hcd uhci_hcd usbcore i810_audio ac97_codec soundcore 3c59x
> mii agpgart
>  CPU:    0
>  EIP:    0060:[<00000000>]    Not tainted VLI
>  EFLAGS: 00010246   (2.6.16.27n-xeno222 #7)
>  EIP is at rest_init+0x3feffde0/0x63
>  eax: c030ba80   ebx: c030ba80   ecx: 00000002   edx: 00000003
>  esi: c030ba80   edi: 00000246   ebp: 00000021   esp: cc1bbf80
>  ds: 007b   es: 007b   ss: 0068
>  Process dd (pid: 11490, threadinfo=cc1ba000 task=d56f8a70)
>  Stack: <0>c013f158 00000021 c030ba80 cc1bbfbc 00000001 c0314408 c030ba80
> cc1bbfbc
>         00000000 00000200 08051000 cc1ba000 c0111c3d 00000000 c0102ec6
> 00000000
>         08051000 00000200 00000200 08051000 bfda2568 00000003 0000007b
> 0000007b
>  Call Trace:
>         [<c013f158>] __ipipe_dispatch_event+0xcd/0xeb
>         [<c0111c3d>] __ipipe_syscall_root+0x2f/0xd8
>         [<c0102ec6>] sysenter_past_esp+0x3b/0x67
>  Code:  Bad EIP value.
>  <4>I-pipe: Domain Xenomai registered.
> Xenomai: hal/x86 started.
> Xenomai: real-time nucleus v2.2.2 (Ride) loaded.
> Xenomai: SMI-enabled chipset found, enabling SMI workaround.
> [..]
> 
> I'm sure somthing is wrong with my kernel-config, so I have attached it,
> together with the xeno-test-output.
> BTW: I tried noapic, acpi=off with no success.

Looks like a cleanup race in the nucleus unloading code. I just got it
here as well after adoption to your .config (all modularised,
CONFIG_PREEMPT). It basically seems to melt down to having high syscall
load (e.g. dd if=/dev/zero of=/dev/null) during nucleus unload.

Unless someone around immediately has an idea why some syscall traps
onto a NULL pointer (or something else - I had non-NULL address here), I
would try to get this over a debugging environment "later". Hope the bug
is not too volatile...

Thanks for reporting so precisely!

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]