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
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
[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
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
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
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 +
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
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.
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.
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,
10 matches
Mail list logo
