I'm raising the system limits as follows:
echo 131072 > /proc/sys/fs/file-max && echo 131072 >
/proc/sys/fs/inode-max
Is this right?
How high can I go?
Does it matter when it gets raised?
Can I lower it again?
Are there docs about how to use the the > 1024 support? I wasn't able
to find anything relevant to 2.2.x or 2.1.1xx.
Will an oops go out over serial console? That could save a lot of error
prone copying....
I think the oops is repeatable under load (it happened before, but I was
in X Windows and didn't see it). In fact, I can crash the system faster
than I can write this message....
I'm not on linux-kernel. Please reply directly.
Thanks,
-Dan Christian
I was testing a 2.2.1-ac3 kernel with the system file-max and inode-max
turn up to 128K.
The system was under heavy load (net, cpu, and disk), and at least one
(threaded) process had over 4K file descriptors in use. The system
wasn't swapping.
The system is a single PPro 200Mhz, 128Mb, TLAN ethernet (10baseT),
AIC-7xxx SCSI (ultra wide), two disks.
I raise the system limit while things were running. This seems like
quite a bad idea in hindsite :-{. It did run for a many seconds past
that. vmstat seemed hosed before the oops (claim 0 0 0 processes even
though the system was working hard).
Here is the oops:
<anything above here scrolled off>
TLAN: Couldn't allocate memory for receive data.
Unable to handle kernel NULL pointer dereference at virtual address
0000005c
current-tss.cr3 = 00101000, %cr3 = 00101000
*pde = 00000000
Oops: 0000
CPU: 0
EIP: 0010:[<c01943da>]
EFLAGS: 00010046
eax: 00000003 ebx: 00000000 ecx: c0004800 edx: 0000004c
esi: c0004800 edi: c01e43a8 ebp: c035e800 esp: c01e9e7c
ds: 0018 es: 0018 ss: 0018
Process swapper (pid: 0, Process nr: 0, stackpage=c01e9000)
Stack: c01e43a8 c019000c c01f5726 00000033 c0004800 c000f078 c0004908
00000286
00000000 00000001 c019363d c01e43a8 0000000c c7bd5b00 04000001
0000000b
c01e9f1c 0000000c c010a781 0000000b c01e43a8 c01e9f1c c01d6584
0000000b
Call Trace: [<c019000c>] [<c019363d>] [<c010a781>] [<c010a53f>]
[<c010877>] [<c0109794>] [<c0100018>]
[<c0117b74>] [<c010a88d>] [<c0109794>] [<c0107f21>] [<c0106000>]
[<c0107f44>] [<c01096f8>] [<c0106000>]
[<c010607b>] [<c0106000>] [<c0100176>]
Code: 39 53 5c 76 0f 89 53 5c 03 93 80 00 00 00 89 93 84 00 00 00
Aiee, killing interrupt handler
Kernel panic: Attempted to kill the idle task!
In swapper task - not syncing
EIP is in:
TLan_HandleRxEOF
ksymoops says the following:
>>EIP: c01943da <unregister_netdev+1f06/4bd0>
Trace: c019000c <secure_tcp_sequence_number+719c/9060>
Trace: c019363d <unregister_netdev+1169/4bd0>
Trace: c010a781 <dump_thread+23b5/23ec>
Trace: c010a53f <dump_thread+2173/23ec>
Trace: c0108770 <dump_thread+3a4/23ec>
Trace: c0109794 <dump_thread+13c8/23ec>
Trace: c0117b74 <get_fast_time+6d0/7c0>
Trace: c01096f8 <dump_thread+132c/23ec>
Trace: c010607b <get_options+7b/418>
Code: c01943da <unregister_netdev+1f06/4bd0> 00000000 <_EIP>:
Code: c01943da <unregister_netdev+1f06/4bd0> 0: 39 53 5c
cmpl %edx,0x5c(%ebx)
Code: c01943dd <unregister_netdev+1f09/4bd0> 3: 76 0f
jbe 14 <_EIP+0x14> c01943ee <unregister_netdev+1f1a/4bd0>
Code: c01943df <unregister_netdev+1f0b/4bd0> 5: 89 53 5c
movl %edx,0x5c(%ebx)
Code: c01943e2 <unregister_netdev+1f0e/4bd0> 8: 03 93 80 00 00
addl 0x80(%ebx),%edx
Code: c01943e7 <unregister_netdev+1f13/4bd0> d: 00
Code: c01943e8 <unregister_netdev+1f14/4bd0> e: 89 93 84 00 00
movl %edx,0x84(%ebx)
Code: c01943ed <unregister_netdev+1f19/4bd0> 13: 00
There was an interesting syslog line many seconds before the oops:
Feb 4 14:48:04 tanker kernel: VFS: file-max limit 4096 reached
-- _______________________________________________________________________ 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/