packets stuck in queue (was: Re: pfinet & ftp & hang, round two (much simpler case)

[Marcus Brinkmann]

On Thu, Jun 07, 2001 at 03:41:26AM +0200, Marcus Brinkmann wrote:
> > reply? 102 > 0 "230- 
> > "
> 
> ftp receives it.
> 
> >   72->21000 ("230- 
> > " -1) = 0 7
> 
> ftpd sends another line.
> 
> >   84->21001 (-1 512)  72->21000 ("230- Most of the programs included with 
> > the Debian GNU/Hurd system are
> 
> ftp (still 84) reads.  ftpd sends even more stuff.

Ok, here is what is going on:

Up to this time, all tcp_do_sendmsg's also transmitted the packet.  There
are several ways this is done, but one is if tcp_snd_test() returns 1,
tcp_write_xmit() is called and transmits the packet.  (In
tcp_push_pending_frames).

Starting from the last line in the log above, the only thing that happens is
that tcp packets are accumulated and queued.  The queue is not processed. 
Nobody transmit the packets.  tcp_snd_test is called and fails with 0, so
tcp_push_pending_frames does nothing. Nothing else feels responsible to do so.

I don't know what is expected to happen here.  I am not sure about the other
packets before, some get through because of the tcp_snd_test succeeding,
some get through because tcp_send_skb is called with force_queue == 0 (I
think).  I can send back traces for all those cases (usable breakpoint is,
for example loopback_xmit).  There are different pathes a packet can take.

However, in the failing case, the road ends at tcp_do_sendmsg.  The packets
are joined in a single packet that is queued and never leaves the queue.

Are there timers responsible to flush the queue once in a while?  Maybe the
timer emulation code is broken?

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann              GNU    http://www.gnu.org    marcus@gnu.org
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de