On Thu, 3 Dec 2009, Damian Lukowski wrote:

quoted

On Thu, 3 Dec 2009, Frederic Leroy wrote:

quoted

On Wed, Dec 02, 2009 at 08:17:44PM +0100, Damian Lukowski wrote:

quoted

could you please printk retrans_stamp just before the return in 
include/net/tcp.h:retransmits_timed_out()?
If the value is not monotonically increasing but is reset to 0 at some
point, this might lead to problems in tcp_write_timeout().
It's the only idea I have now.

Your idea is good.
Only one out of 4 value is not null.

Logs corresponding on http://wwW.starox.org/pub/scp_stall is .10

I make 2 attempts. Printk corresponding to .10 are those after the line 
"wlan1 enter promiscuous mode"

Nice thinking indeed Damian, thanks. ...But but, where exactly did you 
print? ...There are multiple returns and the return false branch is 
expected to have a zero retrans_stamp in a typical case but that is not
a problem because we never use the value.

Yes, it's the retrans_stamp in the subtraction I suspected to be 0.
I also suspect this to happen only in the ca_state < CA_Loss case,
so one first solution might be to return true whenever retrans_stamp == 0.

I suppose adding || !tp->retrans_stamp into the false condition is fine 
as long as we don't then have a connection that can cause a connection 
to hang there forever for some reason (this needs to be understood well 
enough, not just test driven in stables :-)).

Unluckily, I still cannot reproduce the scp stalls here, so it would be nice
if Frederic printed retrans_stamp together with icsk_ca_state and
icsk_retransmits, please.

It wouldn't hurt to know tp->packets_out and tp->retrans_out too, that 
might have some significant w.r.t what happens because of FRTO.


-- 
 i.