lkml.org 
[lkml]   [1999]   [Feb]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
Subject2.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/

\
 
 \ /
  Last update: 2005-03-22 13:50    [W:0.141 / U:0.148 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site