Messages in this thread | | | Date | Thu, 04 Feb 1999 16:19:25 -0800 | From | Dan Christian <> | Subject | 2.2.1-ac3 Oops with many fds |
| |
I was trying to test/use the many file descriptor support, and have a couple questions and an oops.
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/
| |