I am reposting... the oops call stack didn't show up correctly.
>>EIP; c012c504 <free_block+84/d8> <=====
Trace; c011b77a <do_softirq+5a/88>
Trace; c012c82a <kfree+72/98>
Trace; c01d00fd <kfree_skbmem+25/80>
Trace; c01d024b <__kfree_skb+f3/f8>
Trace; c01d0d1d <skb_free_datagram+1d/24>
Trace; c0203a61 <packet_recvmsg+139/148>
Trace; c01cd441 <sock_recvmsg+41/b0>
Trace; c0203928 <packet_recvmsg+0/148>
Trace; c01ce2fd <sys_recvfrom+ad/108>
The oops happened on a box running Linux 2.4.0 and libpcap-0.6.2 (which uses
AF_PACKET socket). The packet received was an arp request. I have syslog indicating
the kernel received the arp request. My pcap application captures arp packet as well.
The calls leading to the oops :
pcap_dispatch ...
sys_recvfrom ...
kfree_skbmem ...free_block.
The oops is not recreatable on demand. However, on another box running 2.4.0-test7,
there is a memory leak. Top reports memory used by my application stable at 0.3%,
but system memory usage keeps going up (reaching 250M used, 4M free before staying
there).
Allen Lau
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
