login
Search
Hi all ...
I am running this kernel module and after sometime the kernel hangs wiht the following message:
Unable to handle kernel NULL pointer dereference at virtual address 00000000
printing eip:
c011f40e
*pde = 00000000
Oops: 0000
CPU: 0
EIP: 0010:[] Tainted: P
EFLAGS: 00010086
eax: 00000000 ebx: c02a1ba4 ecx: c020e1ac edx: c02a1bac
esi: c02a1b54 edi: c02a1980 ebp: 00000001 esp: c0281f34
ds: 0018 es: 0018 ss: 0018
Process swapper (pid: 0, stackpage=c0281000)
Stack: c785bbd8 c011f50d c02a1ba4 c0281f40 c0281f40 00000000 c0297560 fffffffe
00000046 c011bc02 c011bb14 00000000 00000001 c011b943 c0297560 c0295900
00000000 c0281f98 c02443c4 c0108520 c0105300 c0280000 c0280000 ffffe000
Call Trace: [] [] [] [] []
[] [] [] [] [] []
Code: 8b 10 89 5a 04 89 13 89 43 04 89 18 5b c3 8d 74 26 00 81 f9
<0>Kernel panic: Aiee, killing interrupt handler!
In interrupt handler - not syncing
<6>wlan2: SW TICK stuck? bits=0x0 EvStat=8001 IntEn=e018
wlan1: SW TICK stuck? bits=0x0 EvStat=8000 IntEn=e09f
wlan1: SW TICK stuck? bits=0x0 EvStat=8000 IntEn=e09f
Can somebody help me to interpret this message
thank you
Prajakta
You're crashing due to bad code
At a rough guess, the binary-only kernel modules you've loaded contain bad code.
The hex number after "printing eip:" tells you which instruction the CPU was executing at the time it died; after that, you have a CPU state dump, then details of which process context the kernel was using ("Process " line).
Finally, the system gives you a stack dump, and an attempt at a call trace, together with some of the code at the death point.
It then panics ("Kernel panic: Aiee, killing interrupt handler!"), and tells you that you were in an interrupt handler at the time it died.
The wlan messages afterwards aren't from kernel.org code, as far as I can see. You'll need to find the source to the wlan driver to find out what they mean.
Need more information
The tainted:P means you've loaded a proprietary module. I can't find the version of the kernel in your dump.
No one is interested in helping (you=paid[badly], we=free) to debug some old version of the kernel (perheps 2.6.5.9999) used to load proprietary modules (for "special IBM hardware" perhaps from IBM/Suse/Novell/Microsoft).
bla
maybe he's using ndiswrapper?
FWIW, I get this same error
FWIW, I get this same error from a straight kernel 2.6.19.1 directly from kernel.org, without any modules from external or proprietory sources being present.
"this same error"?
What do you mean, you also get a NULL pointer access somewhere in the kernel, i.e. another, totally unrelated, programming error? Or you get exactly the same error, i.e. the same call stack (the error occurs at the same place in the same function, which is called from the same place in the same function, etc..)?
The "Unable to handle kernel NULL pointer dereference at virtual address 00000000" is just the visible symptom. Like a baby crying, this can have multiple reasons. This is why the call stack and register contents are printed.
Do you get tainted:P in your dump?
Or just NULL pointer dereference?
I did not use 2.6.19 since they were merging a lot of code, I waited for 2.6.19.1, but am now using 2.6.20 and waiting for 2.6.21 to stabilise. 2.6.19 may not have been a good version due to the number of distractions: KVM, unionfs (which failed), and many more. I had no trouble with 2.6.19.1. In my case I have 20+ machines to test each new kernel on so I will not brand a new kernel "bad" for any failure when on 19/20 machines it works excellent but on 1/20 machines with some vendor problem with BIOS/peripheral there is a problem, I set that hardware aside until it is supported perfectly (usually) in a later kernel version. In some cases I have to wait 6-12 months until all peripherals are supported, one example is "NforceX" where X>3. I am still setting some "ATI Radeon Express" aside for 1-2 years until either it is supported ok (without "hpet=disable" kernel parm) or I can dump same hardware as Windows XP/Vista junk "game machine".
It is actually amazing that most of "brand new" hardware we can buy works quite well with new Linux kernel. It must indicate that the people creating this hardware maybe do try Linux before shipping. Maybe because it is easier/faster to boot Linux bootcd such as Knoppix than to waste many hours to install "improperly licensed child of the God Bill Gates".