lkml.org 
[lkml]   [1998]   [Mar]   [6]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
FromManfred Petz <>
SubjectRe: Sporadious hang on 2.0.3[0,1,2,3,4pre2]
DateFri, 6 Mar 1998 13:35:15 +0100 (CET)
> > 	.... couldn't get a free skbuff ...
> > 	.... couldn't get a free page ...
> > 
> > There was no output from the debug-skbuff in the logs.
> 
> That one is a machine running totally out of memory. Would it be reasonable
> to expect it to run out of memory ?
> 

No, the machine is almost idle all the time. Somebody noted CONFIG_BRIDGE 
- yes I'd enabled this (don't know why, must be a mistake) and it seems 
that it reveals a memory leak on my machine, but I haven't verified that 
further. 

I've compiled the kernel again without CONFIG_BRIDGE and tortured it
heavily for a couple of hours. From another Linux box I did connects
to the www, smtp and ftp ports of my server simultaneously. About 150 
processes on the remote fired connect-requests to my Linux box.


After about 3 hours the machine crashed. skbuff is at least involved here.
Here's the trace:


 Unable to handle kernel NULL pointer dereference at virtual address c0000008
 current->tss.cr3 = 0046f000, @r3 = 0046f000
 *pde = 00102067
 *pte = 00000000
 Oops: 0000
 CPU:    0
 EIP:    0010:[tcp_recvmsg+609/1088]
 EFLAGS: 00010246
 eax: 00000000   ebx: 00c57cd4   ecx: 00000022   edx: 001a0e1c
 esi: 00000246   edi: 00000000   ebp: 00c57c0c   esp: 0082fee8
 ds: 0018   es: 0018   fs: 002b   gs: 002b   ss: 0018
 Process httpd (pid: 12572, process nr: 24, stackpage=0082f000)
 Stack: 00c57c0c 0082ff7c 00000000 00000000 00000000 00c57c30 00000000 00000000
        011f7414 0067c948 6cb2503e 00159216 00c57c0c 0082ff78 00001000 00000000
        00000000 0082ff7c 00001000 0067c900 080889b4 0067c990 0013b11b 0067c990
 Call Trace: [inet_recvmsg+118/144] [sock_read+171/208] [sys_read+204/256] [system_call+85/128]
 Code: 81 60 08 ff ff fd ff ff 45 44 8b 4c 24 14 e9 2c 01 00 00 8d
 Unable to handle kernel NULL pointer dereference at virtual address c0000008
 current->tss.cr3 = 0146d000, @r3 = 0146d000
 *pde = 00102067

(gdb) disassemble tcp_recvmsg
Dump of assembler code for function tcp_recvmsg:
[SNIP]
0x14d61e <tcp_recvmsg+574>:     addl   $0x4,%esp
0x14d621 <tcp_recvmsg+577>:     movl   0x14(%esp,1),%ecx
0x14d625 <tcp_recvmsg+581>:     movl   0x214(%ebp),%eax
0x14d62b <tcp_recvmsg+587>:     orl    $0x20000,0x8(%eax)
0x14d632 <tcp_recvmsg+594>:     movl   %ecx,0x14(%esp,1)
0x14d636 <tcp_recvmsg+598>:     call   0x112000 <schedule>
0x14d63b <tcp_recvmsg+603>:     movl   0x214(%ebp),%eax
0x14d641 <tcp_recvmsg+609>:     andl   $0xfffdffff,0x8(%eax)
0x14d648 <tcp_recvmsg+616>:     incl   0x44(%ebp)
0x14d64b <tcp_recvmsg+619>:     movl   0x14(%esp,1),%ecx
0x14d64f <tcp_recvmsg+623>:     jmp    0x14d780 <tcp_recvmsg+928>
0x14d654 <tcp_recvmsg+628>:     leal   0x0(%esi),%esi
0x14d65a <tcp_recvmsg+634>:     leal   0x0(%edi),%edi
0x14d660 <tcp_recvmsg+640>:     incw   0x6e(%ebx)
0x14d664 <tcp_recvmsg+644>:     movl   0x34(%ebx),%esi
0x14d667 <tcp_recvmsg+647>:     subl   0x10(%esp,1),%esi
0x14d66b <tcp_recvmsg+651>:     cmpl   %esi,0x38(%esp,1)
0x14d66f <tcp_recvmsg+655>:     jae    0x14d675 <tcp_recvmsg+661>


Which is tcp.c around line 1712:

                cleanup_rbuf(sk);
                release_sock(sk);
                sk->socket->flags |= SO_WAITDATA;
                schedule();
                sk->socket->flags &= ~SO_WAITDATA;
		^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                lock_sock(sk);
                continue;

How can that happen? Could it be a hardware-interrupt-handler? 
Maybe this explains all those strange problems? I've a 3c509 if this
matters.


Does this help? Do you need more information? Any additional
debugging-code I can apply? :-)

I'm currently trying to reproduce that Oops, I'm convinced it happens
again very soon. Note that this one is different to the problems which usually
show up (complete lock-up).


pm

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

\
 
 \ /
  Last update: 2005-03-22 12:41    [from the cache]
©2003-2008