read() returns ETIMEDOUT on steady TCP connection

Andre Oppermann andre at freebsd.org
Fri May 9 10:02:06 UTC 2008


Tim Gebbett wrote:
> Hi all,
> 
> applied the patch,
> 
> Well before a ETIMEDOUT error occurred (around 60secs), the tcp debug started venting massive
> quantities of tcp_output error 55 while sending with syncache noise:

The error seems to be coming from the interface send queue which hits the limit.
If you are using em(4) network interface please add this line to loader.conf(5):

  hw.em.txd=1024

Or even more if problems persist.  The maximum is 4096.

-- 
Andre

> y  8 12:14:26 timtest kernel: :63859 to [192.168.5.40]:80; tcp_output: error 55 whilTeC Ps:e
> n[d1i9n2g. 1(6i8p._5o.u4t3p]u:t64 0371 )t May  8 12:14:26 timtest kernel: o May  8 12:14:26
> timtest kernel: [192.168.5.40]:80; tcp_output: error 55 while sendingT May  8 12:14:26 timtest
> kernel: C May  8 12:14:26 timtest kernel: P: [192.168.5.43]:63859 to [192.168.5.40]:80;
> tcp_output: error 55 while sending May  8 12:14:26 timtest kernel: TCP: [192.168.5.43]:64037 to
> [192.168.5.40]:80; tcp_output: error 55 while sending (ip_output 1) May  8 12:14:26 timtest
> kernel: TCP: [192.168.5.43]:64037 to [192.168.5.40]:80; tcp_output: error 55 while sending May  8
> 12:14:26 timtest kernel: TCP: [192.168.5.43]:63857 to [192.168.5.40]:80; tcp_output: error 55
> while sending (ip_output 1) May  8 12:14:26 timtest kernel: TCP: [192.168.5.42]:56421 toT C[P1:9
> 2[.119628..51.6480.]5:.8403;] :6t3c8p57_ otuot p[u1t9:2 .e1r68r.o5r. 40]:8505;  whticlpe_
> osuetnpduitn:g  e(rirpo_ro utpu5t5  w1h)i
> 
> interspersed with clean blocks of 20 entries or so of:
> 
> May  8 12:14:26 timtest kernel: TCP: [192.168.5.43]:64037 to [192.168.5.40]:80; tcp_output: error
> 55 while sending (ip_output 1) May  8 12:14:26 timtest kernel: TCP: [192.168.5.43]:64037 to
> [192.168.5.40]:80; tcp_output: error 55 while sending May  8 12:14:26 timtest kernel: TCP:
> [192.168.5.43]:63857 to [192.168.5.40]:80; tcp_output: error 55 while sending (ip_output 1)
> 
> 
> The output did not look appreciably different when the ETIMEDOUT occurred.
> 
> On stopping the client test program:
> 
> May  8 12:14:46 timtest kernel: TCP: [192.168.5.43]:63978 to [192.168.5.40]:80 tcpflags 0x4<RST>;
> syncache_chkrst: Spurious RST without matching syncache entry (possibly syncookie only), segment
> ignored May  8 12:14:46 timtest kernel: TCP: [192.168.5.43]:63978 to [192.168.5.40]:80 tcpflags
> 0x4<RST>; syncache_chkrst: Spurious RST without matching syncache entry (possibly syncookie
> only), segment ignored May  8 12:14:46 timtest kernel: TCP: [192.168.5.43]:63978 to
> [192.168.5.40]:80 tcpflags 0x4<RST>; syncache_chkrst: Spurious RST without matching syncache
> entry (possibly syncookie only), segment ignored
> 
> netstat -m
> 
> 258/11007/11265 mbufs in use (current/cache/total) 256/1596/1852/25600 mbuf clusters in use
> (current/cache/total/max) 256/1536 mbuf+clusters out of packet secondary zone in use
> (current/cache) 0/7585/7585/51200 4k (page size) jumbo clusters in use (current/cache/total/max) 
> 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) 0/0/0/3200 16k jumbo clusters in
> use (current/cache/total/max) 576K/36283K/36860K bytes allocated to network (current/cache/total)
>  0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters
> denied (4k/9k/16k) 0/4/6656 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0
> requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain
> routines
> 
> Thanks again for your help - Tim
> 
> 
> 
> 
> 
> 
> 
> 
> 



More information about the freebsd-net mailing list