Re: mm or tlan: Couldn't allocate memory for received data.

[Jorgen Skjaanes]

On Thu, 17 Feb 2000, Mike Galbraith wrote:

> If you'd like, I can extract ikd (large) and send it so you can try
> memleak.  It can give you allocation when/where data.

Thanks, I applied it and it was very interesting. 
It looks like line 477 in net/packet/af_packet.c is allocating
like crazy without much being freed.

First: when the "TLAN: Couldn't allocate memory for received data"
messages come and I after a while pull the network cable and 
thereby stop the tlan-messages, the system is still useless. A simple 
cat command still gives bash: fork: Cannot allocate memory for as long
as 10 minutes after I pulled the plug. It sure looks like a mm/slab-freeing
bug to me. It's not like I'm all out of memory at all. And after a while
the system comes back to live again with saner slabinfo and memleak 
numbers.

Here's the last top-memleak numbers I logged right before the system 
went back to normal:

14553:  af_packet.c:477
 6339:  buffer.c:1105
 5656:  tlan.c:1196
 4771:  memory.c:1004
 2295:  filemap.c:538
 2120:  af_unix.c:1240

(the first number being the allocation count).

An hour earlyer when the tlan-messages first occured it looked 
like this:

 6242:  memory.c:1004
 3688:  buffer.c:1105
 3410:  af_packet.c:477
 3239:  filemap.c:538
 1514:  tlan.c:1196
 1457:  mmap.c:242

and 7 minutes before that again the top leak-numbers was (quite normal):

6431:  memory.c:1004
4638:  buffer.c:1105
2658:  filemap.c:538
1520:  mmap.c:242
1081:  file_table.c:82
 926:  dcache.c:438
 881:  filemap.c:1797
 820:  memory.c:782
 762:  filemap.c:1351
 701:  af_packet.c:477

As allways, I can apply debug-patches and/or provide more info on
request.

-- 
Jorgen