Red Hat Bugzilla – Bug 144590
kernel 2.6.10-1.1074_FC4smp - oops in check_slabuse
Last modified: 2015-01-04 17:15:10 EST
Description of problem:
I got the following pretty soon after booting to level 3
Unable to handle kernel paging request at virtual address ded60ea4
*pde = 0001e426
Oops: 0000 [#1]
Modules linked in: loop nfsd exportfs lockd parport_pc lp parport
autofs4 i2c_dev i2c_core sunrpc ipt_REJECT ipt_state ip_conntrack
iptable_filter ip_tables dm_mod video button battery ac 3c59x floppy
EIP: 0060:[<c013fc66>] Not tainted VLI
EFLAGS: 00010002 (2.6.10-1.1074_FC4smp)
EIP is at check_slabuse+0x3c/0xca
eax: ded60ea4 ebx: dc3d4e60 ecx: 00000001 edx: ded60000
esi: ded60000 edi: 00000000 ebp: df2efb48 esp: dff9bf2c
ds: 007b es: 007b ss: 0068
Process events/0 (pid: 6, threadinfo=dff9b000 task=dfedfac0)
Stack: 00000001 00000001 df2efb48 dc3d4e60 dc3d4db8 dc3d4f54 c013fd48
dc3d4e60 c014012b 00000008 00000000 c140bc00 c140bc04 00000283
c012ae6b 00000000 c0140085 ffffffff ffffffff 00000001 00000000
Code: 0f 84 ac 00 00 00 31 ff 3b bb b8 00 00 00 0f 83 9e 00 00 00 8b
b3 b0 00 00 00 89 d8 0f af f7 03 75 0c 89 f2 e8 b6 dd ff ff 89 f2 <8b>
00 89 44 24 04 89 d8 e8 c6 dd ff ff 31 d2 8b 00 81 7c 24 04
At the moment this happened a machine was not doing outwardly
anything special, although some cron stuff could be runing, and
it was sitting idle at a shell prompt. After that it went possum.
I could not get any response to a keyboard. On a network it
was responding to pings but no login was possible.
This actually is repeatable. While I was typing that report
using another machine the same incident happened again.
SysRq is usable yet and I attach what I managed to collect with
it. The first thing which showed up when trying to use SysRq
<7>atkbd.c: Keyboard on isa0060/serio0 reports too many keys pressed
Kernels 1069 refused to boot on a test machine with symptoms
like described in but #144480 so I did not try to investigate.
I did not see anything similar to the above with any other earlier
Version-Release number of selected component (if applicable):
Looks pretty consistent but one has to wait for some time.
It bombed again.
Created attachment 109525 [details]
sysrq traces after check_slabuse incident
*** This bug has been marked as a duplicate of 144575 ***
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.