freebsd 7.0-RELEASE BUG ping: sendto: No buffer space available

Kip Macy kmacy at freebsd.org
Mon Jan 26 12:12:33 PST 2009


"No buffer space available" is ENOBUFS. This error is returned when
the ifq is full - see IFQ_ENQUEUE in if_var.h. You'll almost certainly
want to set ifq_len to larger than the default for a 10 gigabit
driver. This most likely to be a combination of ifq_len being too
small and inadequate txq overflow handling. However, without the code
to look at I can only guess.

Cheers,
Kip




On Sat, Jan 24, 2009 at 12:54 PM, Yony Yossef <yonyossef.lists at gmail.com> wrote:
> Hi All,
>
> I'm facing a temporary network hang on my interfaces following a flood
> ping/stress udp test.
>
> I'm running a netperf UDP test which is giving results but does not return
> to the shell.
> client output:
>
> UDP UNIDIRECTIONAL SEND TEST from fe80::202:c9ff:fe02:e1fe%mtnic0
> (fe80::202:c9ff:fe02:e1fe) port 0 AF_INET6 to fe80::202:c9ff:fe02:e1f4%mt
> nic0 (fe80::202:c9ff:fe02:e1f4) port 0 AF_INET6
> Socket  Message  Elapsed      Messages
> Size    Size     Time         Okay Errors   Throughput
> bytes   bytes    secs            #      #   10^6bits/sec
>
>  32768    1472   10.02      547428 1694280     643.60
>  32768           10.02       25089             29.50
>
>
> (HANG)
>
> After a minute or two it returns to the shell with the following message:
> shutdown_control: no response received  errno 55
>
> 20 minutes later (!!) the interface is working again.
>
> netstat -m and vmstat -z outputs during the hang time:
>
> # netstat -m
> 25687/6578/32265 mbufs in use (current/cache/total)
> 17404/2438/19842/65536 mbuf clusters in use (current/cache/total/max)
> 0/1024 mbuf+clusters out of packet secondary zone in use (current/cache)
> 2071/1369/3440/65536 4k (page size) jumbo clusters in use
> (current/cache/total/max)
> 0/0/0/65536 9k jumbo clusters in use (current/cache/total/max)
> 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max)
> 49513K/11996K/61510K 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/0/0 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
> You have new mail in /var/mail/root
>
> # vmstat -z | grep mbuf
> ITEM                     SIZE     LIMIT      USED      FREE  REQUESTS
> FAILURES
> mbuf_packet:              256,        0,        0,     1024,     1497,
> 0
> mbuf:                     256,        0,    25687,     5554, 21208920,
> 0
> mbuf_cluster:            2048,    65536,    18428,     1414,   149349,
> 0
> mbuf_jumbo_pagesize:     4096,    65536,     2071,     1369, 17050312,
> 0
> mbuf_jumbo_9k:           9216,    65536,        0,        0,        0,
> 0
> mbuf_jumbo_16k:         16384,     3200,        0,        0,        0,
> 0
> mbuf_ext_refcnt:            4,        0,        0,        0,        0,
> 0
>
> # uname -a
> FreeBSD sw260.lab.mtl.com 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Mon Dec 29
> 11:00:24 UTC 2008
> root at sw259.lab.mtl.com:/usr/obj/usr/src.dbg/sys/GENERIC.KDB  amd64
>
> The fact that the interface is coming back to life without any driver
> activity indicates an OS bug.
>
> Thanks,
> Yony
>
> _______________________________________________
> freebsd-net at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
>


More information about the freebsd-net mailing list