Messages in this thread | | | Date | Fri, 05 Feb 1999 17:32:44 -0800 | From | Dan Christian <> | Subject | 2.2.1-ac5 oops with many fd |
| |
Alan's fix to the TLAN driver seems to work. It will generate "TLAN: Couldn't allocate memory for received data." (at about 100Hz) when the system gets maxed out, but will return to normal operation if the load is reduced.
My application seems to have trouble with new connections after the fd count gets high and then lowers. Restarting the application fixes things. This might be an application problem (but I doubt it). I haven't been able to force an oops or panic.
Given my success so far, I pushed my luck and tried a different system :->
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.
One of the advantages of SMP is that you get an oops much faster :-).
The system experience less then 10 seconds of heavy load before hitting this. Probably over 5000 fds were in use. There were no other messages before the oops. It went down too fast to write anything to syslog.
-Dan
The EIP is in build_sglist in the megaraid driver.
Options used: -V (specified) -O (specified) -k /proc/ksyms (specified) -l /proc/modules (default) -M (specified) -c 1 (default)
Unable to handle kernel NULL pointer dereference at virtual address 00000000 current->tss.cr3 = 7ac3c000, %cr3 = 7ac3c000 *pde = 00000000 Oops: 0002 CPU: 1 EIP: 0010:[<801ab8d2>] EFLAGS: 00010006 eax: 00000000 ebx: 00000000 ecx: 736ab400 edx: 00000000 esi: 80079200 edi: 80082584 ebp: 80082598 esp: fa875d84 ds: 0018 es: 0018 ss: 0018 Process update (pid: 533, process nr: 41, stackpage=fa875000) Stack: 80080078 8019644c 801ab1a1 80080078 80082584 80082598 fa875dc0 80080000 8001c200 80080078 8019644c 80080078 80080970 80082590 80082598 8001c200 801abe9c 80080078 8001c200 00001000 8008004d 80080000 8001c200 801910df Call Trace: [<8019644c>] [<801ab1a1>] [<8019644c>] [<801abe9c>] [<801910df>] [<8 019644c>] [<801aea28>] [<80199537>] [<80197d60>] [<8018ea0b>] [<80162034>] [<80155374>] [<801985 [<8016e566>] [<8016eeaf>] [<8016f05c>] [<80129e47>] [<80129f78>] [<80108c Code: 89 0c d8 8b 44 16 08 8b 4f 58 89 44 d9 04 43 8b 47 08 0f b7
>>EIP: 801ab8d2 <proc_print_scsidevice+1418a/14960> Trace: 8019644c <scsi_sleep+1478/1c18> Trace: 801ab1a1 <proc_print_scsidevice+13a59/14960> Trace: 8019644c <scsi_sleep+1478/1c18> Trace: 801abe9c <proc_print_scsidevice+14754/14960> Trace: 801910df <scsi_do_cmd+4ef/b54> Code: 801ab8d2 <proc_print_scsidevice+1418a/14960> 00000000 <_EIP>: Code: 801ab8d2 <proc_print_scsidevice+1418a/14960> 0: 89 0c d8 m ovl %ecx,(%eax,%ebx,8) Code: 801ab8d5 <proc_print_scsidevice+1418d/14960> 3: 8b 44 16 08 m ovl 0x8(%esi,%edx,1),%eax Code: 801ab8d9 <proc_print_scsidevice+14191/14960> 7: 8b 4f 58 m ovl 0x58(%edi),%ecx Code: 801ab8dc <proc_print_scsidevice+14194/14960> a: 89 44 d9 04 m ovl %eax,0x4(%ecx,%ebx,8) Code: 801ab8e0 <proc_print_scsidevice+14198/14960> e: 43 i ncl %ebx Code: 801ab8e1 <proc_print_scsidevice+14199/14960> f: 8b 47 08 m ovl 0x8(%edi),%eax Code: 801ab8e4 <proc_print_scsidevice+1419c/14960> 12: 0f b7 00 m ovzwl (%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/
| |