TCP 2.2.1-ac5 oops

Dan Christian (robodan@netscape.com)
Wed, 10 Feb 1999 10:29:43 -0800


I hit this oops in tcp, but it might be related to the megaraid problems
that I reported earlier. The system was running a big rm -rf on about
400Mb of small files (on a 3 disk RAID-0) and was starting a application
that does lots of net and disk activity (e-mail servers).

The cool/scary thing was that the megaraid was still updating the disks
for a good two minutes after the system oops'ed.

This system is a Dell 4 way Xeon-1Mb, 2Gb RAM, AMI Megaraid 428 (with
16Mb and battery), version 0.93 driver, version 1.47 BIOS, 6 physical
disks arranged as 3 virtual disks, AIC7xxx for tape and CD, (2) Intel
eepro 100baseT. The kernel is 2.2.1-ac5 with the 2Gb mod, but booted
with mem=960M.

Options used: -v ../../vmlinux (specified)
-o /lib/modules/2.2.1-ac5/ (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-m /usr/src/linux/System.map (default)
-c 1 (default)

Warning in compare_ksyms_lsmod, module nfs is in lsmod but not in ksyms,
probably no symbols exported
Unable to handle kernel NULL pointer dereference at virtual address
00000000
current->tss.cr3 = 1af31000, %cr3 = 1af31000
*pde = 00000000
Oops: 0000
CPU: 3
EIP: 0010:[<80160347>]
EFLAGS: 00010202
eax: 00000019 ebx: 9b0dc640 ecx: 9e040019 edx: 00000000
esi: 00000080 edi: 00000200 ebp: 7ffffa58 esp: 9e04ff6c
ds: 0018 es: 0018 ss: 0018
Process smtpd (pid: 4180, process nr: 274, stackpage=9e04f000)
Stack: 80166f2d 9b0dc640 8f9a2988 9e04e000 8014b7cb 8f9a2988 00000200
00000003
7ffffa3c 00000004 8014c507 8014c5b7 00000004 00000200 9e04e000
00000004
00000200 00000009 7ffffa4c 00000004 b68852a0 80108c00 00000004
7ffff9e4
Call Trace: [<80166f2d>] [<8014b7cb>] [<8014c507>] [<8014c5b7>]
[<80108c00>]
Code: 66 39 0a 74 08 8b 52 04 66 39 0a 75 f8 83 7a 08 00 75 1e 80

>>EIP: 80160347 <tcp_v4_rehash+cb/148>
Trace: 80166f2d <inet_listen+8d/100>
Trace: 8014b7cb <sys_listen+47/74>
Trace: 8014c507 <sys_socketcall+33/248>
Trace: 8014c5b7 <sys_socketcall+e3/248>
Trace: 80108c00 <system_call+34/38>
Code: 80160347 <tcp_v4_rehash+cb/148> 00000000 <_EIP>:
Code: 80160347 <tcp_v4_rehash+cb/148> 0: 66 39 0a
cmpw %cx,(%edx)
Code: 8016034a <tcp_v4_rehash+ce/148> 3: 74 08
je d <_EIP+0xd> 80160354 <tcp_v4_rehash+d8/148>
Code: 8016034c <tcp_v4_rehash+d0/148> 5: 8b 52 04
movl 0x4(%edx),%edx
Code: 8016034f <tcp_v4_rehash+d3/148> 8: 66 39 0a
cmpw %cx,(%edx)
Code: 80160352 <tcp_v4_rehash+d6/148> b: 75 f8
jne 5 <_EIP+0x5> 8016034c <tcp_v4_rehash+d0/148>
Code: 80160354 <tcp_v4_rehash+d8/148> d: 83 7a 08 00
cmpl $0x0,0x8(%edx)
Code: 80160358 <tcp_v4_rehash+dc/148> 11: 75 1e
jne 31 <_EIP+0x31> 80160378 <tcp_v4_rehash+fc/148>
Code: 8016035a <tcp_v4_rehash+de/148> 13: 80 00 00
addb $0x0,(%eax)

Here is the previous oops (properly symbolled this time). This is the
same setup, but it was using the full 2Gb. The system was under a
similar load (but no big "rm -rf" going on).

Options used: -v ../../vmlinux (specified)
-o /lib/modules/2.2.1-ac5/ (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-m /usr/src/linux/System.map (default)
-c 1 (default)

Warning in compare_ksyms_lsmod, module nfs is in lsmod but not in ksyms,
probably no symbols exported
Unable to handle kernel NULL pointer dereference at virtual address
00000000
current->tss.cr3 = 6e151000, %cr3 = 6e151000
*pde = 00000000
Oops: 0002
CPU: 1
EIP: 0010:[<801ab8d2>]
EFLAGS: 00010006
eax: 00000000 ebx: 00000000 ecx: 69edf800 edx: 00000000
esi: 80078a00 edi: 80082104 ebp: 80082118 esp: ee153d84
ds: 0018 es: 0018 ss: 0018
Process update (pid: 538, process nr: 28, stackpage=ee153000)
Stack: 80080078 8019644c 801ab1a1 80080078 80082104 80082118 ee153dc0
80080000
8008b800 80080078 8019644c 80080078 80080a30 80082110 80082118
8008b800
801abe9c 80080078 8008b800 00010800 80080041 80080000 8008b800
801910df
Call Trace: [<8019644c>] [<801ab1a1>] [<8019644c>] [<801abe9c>]
[<801910df>] [<8019644c>] [<801aea28>]
[<80199537>] [<80197d60>] [<801910df>] [<8019644c>] [<801aea28>]
[<80197a76>] [<80199537>] [<801985f7>]
[<80198638>] [<8016e3ed>] [<8016e566>] [<8016eeaf>] [<8016f05c>]
[<80129e47>] [<80129f78>] [<80108c00>]
Code: 89 0c d8 8b 44 16 08 8b 4f 58 89 44 d9 04 43 8b 47 08 0f b7

>>EIP: 801ab8d2 <build_sglist+6e/ac>
Trace: 8019644c <scsi_old_done+0/5ec>
Trace: 801ab1a1 <mega_build_cmd+33d/414>
Trace: 8019644c <scsi_old_done+0/5ec>
Trace: 801abe9c <megaraid_queue+58/b4>
Trace: 801910df <scsi_do_cmd+4ef/588>
Trace: 8019644c <scsi_old_done+0/5ec>
Trace: 801aea28 <sprintf+14/e44>
Trace: 80199537 <requeue_sd_request+eef/f00>
Trace: 80198638 <do_sd_request+1e4/1f4>
Code: 801ab8d2 <build_sglist+6e/ac> 00000000 <_EIP>:
Code: 801ab8d2 <build_sglist+6e/ac> 0: 89 0c d8
movl %ecx,(%eax,%ebx,8)
Code: 801ab8d5 <build_sglist+71/ac> 3: 8b 44 16 08
movl 0x8(%esi,%edx,1),%eax
Code: 801ab8d9 <build_sglist+75/ac> 7: 8b 4f 58
movl 0x58(%edi),%ecx
Code: 801ab8dc <build_sglist+78/ac> a: 89 44 d9 04
movl %eax,0x4(%ecx,%ebx,8)
Code: 801ab8e0 <build_sglist+7c/ac> e: 43
incl %ebx
Code: 801ab8e1 <build_sglist+7d/ac> f: 8b 47 08
movl 0x8(%edi),%eax
Code: 801ab8e4 <build_sglist+80/ac> 12: 0f b7 00
movzwl (%eax),%eax

--
_______________________________________________________________________
Disraeli was pretty close: actually, there are Lies, Damn lies, Statistics,
Benchmarks, and Delivery dates.

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/