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