Messages in this thread | | | Date | Wed, 10 Feb 1999 10:29:43 -0800 | From | Dan Christian <> | Subject | TCP 2.2.1-ac5 oops |
| |
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/
| |