Subject: Re: no buffer space available
To: NetBSD User's Discussion List <netbsd-users@netbsd.org>
From: Steven M. Bellovin <smb@research.att.com>
List: netbsd-users
Date: 06/24/2001 19:17:13
In message <20010624215134.A3515D0@proven.weird.com>, Greg A. Woods writes:
>[ On Sunday, June 24, 2001 at 14:46:21 (-0500), emre@vsrc.uab.edu wrote: ]
>> Subject: Re: no buffer space available
>>
>> I havent been really paying attention to this thread, but
>> maybe increasing the value of kern.mbuf.nmbclusters with sysctl -w might
>> fix the problem.  Or you might want to recompile your kernel with a higher
>> value for NMBCLUSTERS.
>
>The last time my router "froze" up with this very similar problem
>'netstat -m' only showed about "12% in use), and it indicated that
>there'd never been any requests for memory denied or delayed.
>
>There's considerably less in use now, but there hasn't been a reboot in
>the mean time:
>
>	$ netstat -m
>	2 mbufs in use:
>	        1 mbufs allocated to data
>	        1 mbufs allocated to packet headers
>	0/14 mapped pages in use
>	100 Kbytes allocated to network (0% in use)
>	0 requests for memory denied
>	0 requests for memory delayed
>	0 calls to protocol drain routines
>
>Is the netstat memory accounting broken?
>
>Neither my cable modem nor DSL links were conjested at the time either
>(though IIRC I was listening to an _incoming_ 128kbit MP3 stream shortly
>before that).
>
>The interface that was stuck was actually the LAN too, not either of the
>ethernets to the DSL/cable modems.  It's half-duplex, but on a switched
>segment and the collision rate is less than one percent.

You can get ENOBUFS when the output queue for the device is full, I 
believe.  Note the following code fragment from if_ppp.c:

        if (IF_QFULL(ifq) && dst->sa_family != AF_UNSPEC) {
            IF_DROP(ifq);
            splx(s);
            sc->sc_if.if_oerrors++;
            sc->sc_stats.ppp_oerrors++;
            error = ENOBUFS;
            goto bad;
        }
        IF_ENQUEUE(ifq, m0);
        ppp_restart(sc);

The most likely cause of persistent full queues on a PPP link is 
probably that the modem has flow-controlled the UART, I'd guess.  It 
might pay to try to check the flow control flags when that happens.  Or 
run 'netstat -id' and see what's happening to the queue drop figure.

		--Steve Bellovin, http://www.research.att.com/~smb