Re: [9fans] 9pcfs mballoc bug info

[nemo@gsyc.escet.urjc.es]

[-- Attachment #1: Type: text/plain, Size: 864 bytes --]

The bug happens only when the net is *sloooow* to send the
first packet (seems to happen w/ the arp requests being
sent). I can reproduce the bug quite easily by starting
a fs kernel and attaching to it from a different building
in our campus (yes, our network is slow :-( ).

I think that what happens is that a message buffer gets
linked twice in the transmit ring, perhaps due to a timeout
and retransmission.

Nevertheless, I had to get a fs up quickly and stopped
debugging by now to install one (within the same building,
hence working ;-) ).

My current problem is that although the box has two 4G IDE
disks, the fs kernel thinks the file system is full even
before unpacking the plan9.9gz package.

In case somebody has a hint about what I am doing wrong,
my config string for the device was ch0fh2.

Perhaps I'm just too sleepy...


[-- Attachment #2: Type: message/rfc822, Size: 2358 bytes --]

From: "Boyd Roberts" <boyd@planete.net>
To: <9fans@cse.psu.edu>
Subject: Re: [9fans] 9pcfs mballoc bug info
Date: Mon, 5 Feb 2001 18:56:54 +0100
Message-ID: <037001c08f9d$068b3e00$0ab9c6d4@cybercable.fr>

> Didn't fix it yet, but in my case, txstart905() (plan9pc/etherlnk3.c)
> calls mbfree()  twice with the same buffer. Only transmit() and interrupt()
> (same file) call txstart905; and both routines hold the ilock on ctlr->wlock.

these dup frees are rarely easy to track down.  i'd add some code
before the free to detect it and print some debug, before the panic
leaves you with just a hex stack backtrace.  unfortunately this
may change the timing and the problem may go away.