Red Hat Bugzilla – Bug 86573
kernel NULL pointer dereference
Last modified: 2007-11-30 17:06:52 EST
Unable to handle kernel NULL pointer dereference at virtual address 0000002c *pde = 1f7e4001 Oops: 0000 Kernel 2.4.9-e.12enterprise CPU: 5 EIP: 0010:[<c011966b>] Tainted: P EFLAGS: 00010003 EIP is at schedule [kernel] 0x1bb eax: 0000008c ebx: c03577a0 ecx: c03577c0 edx: e3fb4000 esi: ffffffd4 edi: e3fb4000 ebp: e3fb5dac esp: e3fb5d8c ds: 0018 es: 0018 ss: 0018 Process oracle (pid: 10300, stackpage=e3fb5000) Stack: e665e01c d1622bb8 c01f8579 d1622a80 e3fb4000 7fffffff d1622ab4 e3fb4000 c039c7e0 c0125454 e3fb5e06 e3fb5de8 d84e18e0 00000000 e3fb4000 0a2831f6 00000282 d1622a80 d1622a80 d1622ab4 c01f8b3f e3fb5e04 00000000 e3fb4000 Call Trace: [<c01f8579>] tcp_sendmsg [kernel] 0xf59 [<c0125454>] schedule_timeout [kernel] 0x14 [<c01f8b3f>] tcp_data_wait [kernel] [<c01f8c28>] tcp_prequeue_process [kernel] 0x58 [<c01f919f>] tcp_recvmsg [kernel] 0x4ff [<c01efd3a>] ip_rcv [kernel] 0x35a [<c0212959>] inet_recvmsg [kernel] 0x39 [<c01d7311>] sock_recvmsg [kernel] 0x31 [<c01de9bb>] netif_rx [kernel] 0x9b [<c01dee6b>] net_rx_action [kernel] 0x1eb [<c01d7428>] sock_read [kernel] 0x88 [<c0146996>] sys_read [kernel] 0x96 [<c012061b>] sys_gettimeofday [kernel] 0x1b [<c01072e3>] system_call [kernel] 0x33 Code: 8b 46 58 89 45 ec 8b 47 54 89 45 e8 8b 4d ec 85 c9 75 32 89 <0>Kernel panic: not continuing NMI Watchdog detected LOCKUP on CPU2, eip c02387b3, registers: Kernel 2.4.9-e.12enterprise CPU: 2 EIP: 0010:[<c02387b3>] Tainted: P EFLAGS: 00000082 EIP is at stext_lock [kernel] 0x7b3 eax: 0000005f ebx: e3fb4000 ecx: 00003020 edx: c0f45d50 esi: c03577a0 edi: 00000000 ebp: c0f45d60 esp: c0f45d48 ds: 0018 es: 0018 ss: 0018 Process oracle (pid: 11302, stackpage=c0f45000) Stack: c0f45d50 00000001 00000002 e3fb5e0c 00000001 d8e72dc0 c0f45d88 c01198c2 e3fb4000 00000000 d8e72dc4 00000286 00000001 d1622bec d1622a80 cd560a20 d1622bb8 c020819b f0c57ee0 000005f6 00000002 000005f6 00000000 e768b042 Call Trace: [<c01198c2>] __wake_up [kernel] 0x42 [<c020819b>] tcp_v4_rcv [kernel] 0x39b [<c0125454>] schedule_timeout [kernel] 0x14 [<c0120d3b>] do_softirq [kernel] 0x7b [<c0207d14>] tcp_v4_do_rcv [kernel] 0x94 [<c01ef94b>] ip_local_deliver [kernel] 0x12b [<c01efd3a>] ip_rcv [kernel] 0x35a [<c01efd3a>] ip_rcv [kernel] 0x35a [<c0212959>] inet_recvmsg [kernel] 0x39 [<c01d7311>] sock_recvmsg [kernel] 0x31 [<c01de9bb>] netif_rx [kernel] 0x9b [<c01dee6b>] net_rx_action [kernel] 0x1eb [<f8a9724a>] e100intr [e100] 0x18a [<c0120d3b>] do_softirq [kernel] 0x7b [<c0108e0e>] do_IRQ [kernel] 0xfe [<c0245c30>] call_do_IRQ [kernel] 0x5 [<c01072b0>] system_call [kernel] 0x0 Code: 7e f5 e9 76 02 ee ff 80 be 80 47 35 c0 00 f3 90 7e f5 e9 4e
Ok... there's nothing in here on what happened to cause it, nor if it's reproducable. Would that information be available?
You know as much as we do; this occured during normal machine operations, no obvious trigger. The server was obviously running an oracle database, but beyond that, this "just happened".
Unable to handle kernel paging request at virtual address ffffff92 printing eip: fe22a2a7 *pde = 00003063 Oops: 0002 Kernel 2.4.9-e.38smp CPU: 0 EIP: 0010:[usb-ohci:sohci_device_operations+92772263/3446649] Not tainted EIP: 0010:[<fe22a2a7>] Not tainted EFLAGS: 00010206 EIP is at ignore [ide-cd] 0x57b68d7 eax: 00000000 ebx: fe22a2a7 ecx: 00000003 edx: 0adf6f80 esi: 0adf6f96 edi: ccd5f5c5 ebp: f027a1b8 esp: f2d01e28 ds: 0018 es: 0018 ss: 0018 Process oracle (pid: 1260, stackpage=f2d01000) Stack: 000000fb fffffff2 f2b09520 c01f6ee5 0adf6f5e ccd5f58d 000000fb 00000000 f2d01e98 00000000 00000000 f2af23a0 00000020 f027a080 f2b09ac0 00000020 f2d01e98 ccd5f58d 000004ad f2d00000 0adf6f5e 000007db 00000000 000005a8 Call Trace: [tcp_sendmsg+1173/4672] tcp_sendmsg [kernel] 0x495 (0xf2d01e34) Call Trace: [<c01f6ee5>] tcp_sendmsg [kernel] 0x495 (0xf2d01e34) [tcp_v4_rcv+1005/1632] tcp_v4_rcv [kernel] 0x3ed (0xf2d01ea0) [<c02076fd>] tcp_v4_rcv [kernel] 0x3ed (0xf2d01ea0) [inet_sendmsg+53/64] inet_sendmsg [kernel] 0x35 (0xf2d01ed0) [<c0211e35>] inet_sendmsg [kernel] 0x35 (0xf2d01ed0) [sock_sendmsg+108/144] sock_sendmsg [kernel] 0x6c (0xf2d01ee4) [<c01d692c>] sock_sendmsg [kernel] 0x6c (0xf2d01ee4) [alloc_skb+252/464] alloc_skb [kernel] 0xfc (0xf2d01f20) [<c01d9ccc>] alloc_skb [kernel] 0xfc (0xf2d01f20) [sock_write+167/192] sock_write [kernel] 0xa7 (0xf2d01f38) [<c01d6b57>] sock_write [kernel] 0xa7 (0xf2d01f38) [sys_write+150/288] sys_write [kernel] 0x96 (0xf2d01f7c) [<c0145df6>] sys_write [kernel] 0x96 (0xf2d01f7c) [do_IRQ+254/272] do_IRQ [kernel] 0xfe (0xf2d01fa8) [<c0108f7e>] do_IRQ [kernel] 0xfe (0xf2d01fa8) [system_call+51/56] system_call [kernel] 0x33 (0xf2d01fc0) [<c01073e3>] system_call [kernel] 0x33 (0xf2d01fc0) Problem still seems to exist. The correlations between the 2 tickets are that both machines is running Oracle and using e1000 cards.
We could never reproduce this problem in order to debug it. If this happens in RHEL3 please open up a separate bug. Larry Woodman