dhclient: send_packet: No buffer space available
Hello, Since I have updated my netbook to r255948 I see from time to time in the console the message: Nov 1 16:20:28 tiny-r255948 dhclient[696]: send_packet: No buffer space available The WLAN for the rest works fine without any problem or hick-ups and dhclient always gets and assigns the IP to the wlan0 (ath0) interface. Any idea? Thx matthias -- Matthias Apitz | /\ ASCII Ribbon Campaign: www.asciiribbon.org E-mail: g...@unixarea.de | \ / - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | X - No proprietary attachments phone: +49-170-4527211 | / \ - Respect for open standards ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: dhclient: send_packet: No buffer space available
On Fri, Nov 1, 2013 at 8:32 AM, Matthias Apitz g...@unixarea.de wrote: Hello, Since I have updated my netbook to r255948 I see from time to time in the console the message: Nov 1 16:20:28 tiny-r255948 dhclient[696]: send_packet: No buffer space available Yes, this is a knownish issue which doesn't _seem_ to cause any other side-effects but its getting annoying now. I also see a lot of them lately. I do not think this has been tracked down yet. Cheers, Hiren ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: dhclient: send_packet: No buffer space available
On 1 November 2013 08:45, hiren panchasara hiren.panchas...@gmail.com wrote: On Fri, Nov 1, 2013 at 8:32 AM, Matthias Apitz g...@unixarea.de wrote: Hello, Since I have updated my netbook to r255948 I see from time to time in the console the message: Nov 1 16:20:28 tiny-r255948 dhclient[696]: send_packet: No buffer space available Yes, this is a knownish issue which doesn't _seem_ to cause any other side-effects but its getting annoying now. I also see a lot of them lately. I do not think this has been tracked down yet. Well, the first thing to establish is whether it's occuring in net80211 or the driver. I _think_ it's a net80211 problem, where dhclient is sending a frame to an interface that isn't yet ready. It's yet another race condition that I must've uncovered when I made the switch to if_transmit() in net80211. Yes, I'd love it if someone looked into it for me. :) -adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: send_packet: No buffer space available
Andrea Campi wrote: Well, you're sending out packets faster than your hardware can transmit them. So, at least now we know what to answer if the question arises again (I has several people who send 'me too' emails to me). I was having the same problem on my 4.4-RELEASE box. After swapping the Digital (dc) ethernet card for a 3COM (xl) one (and getting rid of a few bogus route entries), the messages stopped appearing and the system has been running fine ever since. I haven't checked if the digital card works well in another box, so I'm not sure if it's the driver, the card or the route entries. Cheers, Walter. -- Walter Belgers Si hoc signum legere potes, operis boni in rebus [EMAIL PROTECTED] Latinis alacribus et fructuosis potiri potes! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: send_packet: No buffer space available
So this means the output queue on my net card is full, right? And I guess there is no easy solution... Oh well, I'll have to cope. That's correct; the pipe is full, and you can't put any more bits in it. Typically you run into this situation when your app is generating more data than can squirt out the hole in your network card, or the card is stalled for some reason. Any app using socket I/O should be ready to handle ENOBUFS gracefully; it typically needs to pause and then retry the I/O. So, no solution, right? :( If the card is stalled (possible), then you may have a driver problem. But otherwise, it's not a problem except in the application. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: send_packet: No buffer space available
On Mon, Nov 26, 2001 at 05:49:01PM +0100, Andrea Campi wrote:
OK, I traced it to sys/netinet/ip_output.c:
/*
* Verify that we have any chance at all of being able to queue
* the packet or packet fragments
*/
if ((ifp-if_snd.ifq_len + ip-ip_len / ifp-if_mtu + 1) =
ifp-if_snd.ifq_maxlen) {
error = ENOBUFS;
ipstat.ips_odropped++;
goto bad;
}
So this means the output queue on my net card is full, right? And I guess
It means that the interface output queue is full, yes.
there is no easy solution... Oh well, I'll have to cope. But I still wonder,
shouldn't this show up on netstat -i? netstat -s does show the dropped packets,
anyway...
I'm not sure about this. In fact, that's a good question. Usually,
if the queue is full, we should increment ifp-if_snd.ifq_drops as well
as ipstat.ips_odropped. Perhaps this test ought to be more like:
[lock ifp-if_snd]
if ((ifp-if_snd.ifq_len + ip-ip_len / ifp-if_mtu + 1)
ifp-if_snd.ifq_maxlen) {
error = ENOBUFS;
_IFQ_DROP(ifp-if_snd);
ipstat.ips_odropped++;
goto bad;
}
[queue packet...]
[etc...]
[unlock ifp-if_snd]
Note that we presently don't lock anything (this is expected, we
haven't gotten there yet). However, note also that in the new version we
also do an _IFQ_DROP() if we have exceeded the ifq_maxlen, and
finally, also note that the new test is and not = - I don't know
why it is = to begin with. One would think that we should be testing
for whether we are going to _exceed_ ifq_maxlen, not if we're going to
reach it (we should be allowed to reach it).
You should take my suggestion here with a grain of salt, and I think
the best person to comment on this is Jonathan Lemon. summons jlemon
So, no solution, right? :(
Well, you're sending out packets faster than your hardware can
transmit them. You can `artificially' define IFQ_MAXLEN to something
greater than 50 but practically, you probably won't get much besides for
consuming more memory for the output queue.
Bye,
Andrea
--
The best things in life are free, but the
expensive ones are still worth a look.
--
Bosko Milekic
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: send_packet: No buffer space available
Note that we presently don't lock anything (this is expected, we haven't gotten there yet). However, note also that in the new version we also do an _IFQ_DROP() if we have exceeded the ifq_maxlen, and finally, also note that the new test is and not = - I don't know why it is = to begin with. One would think that we should be testing for whether we are going to _exceed_ ifq_maxlen, not if we're going to reach it (we should be allowed to reach it). OK, this makes a lot of sense. So, no solution, right? :( Well, you're sending out packets faster than your hardware can transmit them. You can `artificially' define IFQ_MAXLEN to something greater than 50 but practically, you probably won't get much besides for consuming more memory for the output queue. Well, my main worry is to make sure FreeBSD works at least as well as any other OS our customers may be using or familiar with; I'm not really worried about performance of my -CURRENT laptop (or I'd run -STABLE ;-). Given that it's more of an hardware issue, I'm not really tempted to hack around it, expecially given that you admit it won't do much. So, at least now we know what to answer if the question arises again (I has several people who send 'me too' emails to me). Thanks for helping, Bye, Andrea -- The three Rs of Microsoft support: Retry, Reboot, Reinstall. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: send_packet: No buffer space available
On Wed, Nov 21, 2001 at 06:43:18PM -0500, Bosko Milekic wrote: From the netstat output, it looks more like an application-level problem having to do with exhausting socket buffer space. Whatever the cause of the problem, it certainly isn't a lack of mbufs and/or clusters. Sorry, my bad. It's actually dhclient which is printing this message when sendto(2) returns ENOBUFS. I had already traced this into the kernel and manage to post without double checking my memories... Anyway, it appears that the application isn't to blame, and the card isn't hosed either (I can usually manage to at least get pings through). So it must be the syscall failing, right? OK I'll just go back to adding printf's to the kernel and see what happens. Bye, Andrea Try verifying what is generating the messages. It could be coming from a syscall or, it may be that the application is printing them. If it is the latter (you should find the string in the application code), then it's fairly trivial to figure the rest out. If not, I'd check the network card driver you're using next. On Wed, Nov 21, 2001 at 05:01:16PM +0100, Andrea Campi wrote: This is a long-standing problem which is getting more and more annoying (or so I feel, might be just an impression). I was wondering if anybody might be interested in helping me debug and fix it. I can repeat this at will using Tivoli Storage Manager for Linux to backup my -CURRENT laptop. Basically, after a few minutes I start getting these messages; at that point networking is basically hosed until I kill TSM. First of all, is this just an application misbehaving and it should be fixed only by tuning some sysctl, or is it an OS bug proper? Note that -STABLE doesn't exhibit this problem. netstat -m output is as follow: mbuf usage: GEN list: 0/0 (in use/in pool) CPU #0 list:71/144 (in use/in pool) Total: 71/144 (in use/in pool) Maximum number allowed on each CPU list: 512 Maximum possible: 18432 Allocated mbuf types: 46 mbufs allocated to data 25 mbufs allocated to packet headers 0% of mbuf map consumed mbuf cluster usage: GEN list: 0/0 (in use/in pool) CPU #0 list:20/66 (in use/in pool) Total: 20/66 (in use/in pool) Maximum number allowed on each CPU list: 128 Maximum possible: 9216 0% of cluster map consumed 168 KBytes of wired memory reserved (34% in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines Relevant parts of vmstat -m: Memory statistics by type Type Kern Type InUse MemUse HighUse Limit Requests Limit Limit Size(s) mbufmgr6531K 32K 31594K 2687850 0 16,32,64,128,8K,32K What else is needed to diagnose this? It's been baffling me for much too long... Bye, Andrea -- Tagline generated by 'gensig' mail-client-independent .signature generator. Get your copy at http://www.geeks.com/~robf/gensig/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- Bosko Milekic [EMAIL PROTECTED] -- It's not a bug, it's tradition! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
send_packet: No buffer space available
This is a long-standing problem which is getting more and more annoying (or so I feel, might be just an impression). I was wondering if anybody might be interested in helping me debug and fix it. I can repeat this at will using Tivoli Storage Manager for Linux to backup my -CURRENT laptop. Basically, after a few minutes I start getting these messages; at that point networking is basically hosed until I kill TSM. First of all, is this just an application misbehaving and it should be fixed only by tuning some sysctl, or is it an OS bug proper? Note that -STABLE doesn't exhibit this problem. netstat -m output is as follow: mbuf usage: GEN list: 0/0 (in use/in pool) CPU #0 list:71/144 (in use/in pool) Total: 71/144 (in use/in pool) Maximum number allowed on each CPU list: 512 Maximum possible: 18432 Allocated mbuf types: 46 mbufs allocated to data 25 mbufs allocated to packet headers 0% of mbuf map consumed mbuf cluster usage: GEN list: 0/0 (in use/in pool) CPU #0 list:20/66 (in use/in pool) Total: 20/66 (in use/in pool) Maximum number allowed on each CPU list: 128 Maximum possible: 9216 0% of cluster map consumed 168 KBytes of wired memory reserved (34% in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines Relevant parts of vmstat -m: Memory statistics by type Type Kern Type InUse MemUse HighUse Limit Requests Limit Limit Size(s) mbufmgr6531K 32K 31594K 2687850 0 16,32,64,128,8K,32K What else is needed to diagnose this? It's been baffling me for much too long... Bye, Andrea -- Tagline generated by 'gensig' mail-client-independent .signature generator. Get your copy at http://www.geeks.com/~robf/gensig/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: send_packet: No buffer space available
From the netstat output, it looks more like an application-level problem having to do with exhausting socket buffer space. Whatever the cause of the problem, it certainly isn't a lack of mbufs and/or clusters. Try verifying what is generating the messages. It could be coming from a syscall or, it may be that the application is printing them. If it is the latter (you should find the string in the application code), then it's fairly trivial to figure the rest out. If not, I'd check the network card driver you're using next. On Wed, Nov 21, 2001 at 05:01:16PM +0100, Andrea Campi wrote: This is a long-standing problem which is getting more and more annoying (or so I feel, might be just an impression). I was wondering if anybody might be interested in helping me debug and fix it. I can repeat this at will using Tivoli Storage Manager for Linux to backup my -CURRENT laptop. Basically, after a few minutes I start getting these messages; at that point networking is basically hosed until I kill TSM. First of all, is this just an application misbehaving and it should be fixed only by tuning some sysctl, or is it an OS bug proper? Note that -STABLE doesn't exhibit this problem. netstat -m output is as follow: mbuf usage: GEN list: 0/0 (in use/in pool) CPU #0 list:71/144 (in use/in pool) Total: 71/144 (in use/in pool) Maximum number allowed on each CPU list: 512 Maximum possible: 18432 Allocated mbuf types: 46 mbufs allocated to data 25 mbufs allocated to packet headers 0% of mbuf map consumed mbuf cluster usage: GEN list: 0/0 (in use/in pool) CPU #0 list:20/66 (in use/in pool) Total: 20/66 (in use/in pool) Maximum number allowed on each CPU list: 128 Maximum possible: 9216 0% of cluster map consumed 168 KBytes of wired memory reserved (34% in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines Relevant parts of vmstat -m: Memory statistics by type Type Kern Type InUse MemUse HighUse Limit Requests Limit Limit Size(s) mbufmgr6531K 32K 31594K 2687850 0 16,32,64,128,8K,32K What else is needed to diagnose this? It's been baffling me for much too long... Bye, Andrea -- Tagline generated by 'gensig' mail-client-independent .signature generator. Get your copy at http://www.geeks.com/~robf/gensig/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- Bosko Milekic [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
