Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 86573 - kernel NULL pointer dereference
Summary: kernel NULL pointer dereference
Alias: None
Product: Red Hat Enterprise Linux 2.1
Classification: Red Hat
Component: kernel
Version: 2.1
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Larry Woodman
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2003-03-25 20:55 UTC by Red Hat Production Operations
Modified: 2007-11-30 22:06 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2005-09-29 01:16:13 UTC
Target Upstream Version:

Attachments (Terms of Use)

Description Need Real Name 2003-03-25 20:55:53 UTC
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

Comment 1 Suzanne Hillman 2003-08-15 13:33:19 UTC
Ok... there's nothing in here on what happened to cause it, nor if it's
reproducable. Would that information be available?

Comment 2 Need Real Name 2003-08-15 14:19:55 UTC
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".

Comment 3 Bastien Nocera 2004-06-11 12:25:44 UTC
Unable to handle kernel paging request at virtual address ffffff92
 printing eip:
*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
       f2d01e98 00000000 00000000 f2af23a0 00000020 f027a080 f2b09ac0
       f2d01e98 ccd5f58d 000004ad f2d00000 0adf6f5e 000007db 00000000
Call Trace: [tcp_sendmsg+1173/4672] tcp_sendmsg [kernel] 0x495
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.

Comment 5 Larry Woodman 2005-09-29 01:16:13 UTC
We could never reproduce this problem in order to debug it.  If this happens in
RHEL3 please open up a separate bug.

Larry Woodman

Note You need to log in before you can comment on or make changes to this bug.