On 10/20/2018 4:31 AM, Dave Cottlehuber wrote:
> On Fri, 19 Oct 2018, at 19:46, Mike Tancsa wrote:
>> Feeding entropy: .
>> lo0: link state changed to UP
>> sendmsg on igb0: No buffer space available
>> igb0: link state changed to UP
>> cxl1: link state changed to
On Fri, 19 Oct 2018, at 19:46, Mike Tancsa wrote:
> Feeding entropy: .
> lo0: link state changed to UP
> sendmsg on igb0: No buffer space available
> igb0: link state changed to UP
> cxl1: link state changed to UP
> Starting Network: lo0 igb0 cxl0 cxl1.
I’m reasonably sure tha
Since starting to test HEAD, I noticed at bootup time I get the message
in dmesg
sendmsg on igb0: No buffer space available
It seems innocuous enough in that I dont see any obvious issues. Is it
a symptom of some misconfiguration ? This originally was a releng11 box
that I upgraded via source
Hi!
> On Tue, May 16, 2017 at 06:56:23AM +0200, O. Hartmann wrote:
> > Since the introduction of IFLIB, I have big trouble with especially a
> > certain
> > type of NIC, namely formerly known igb and em.
Please submit a PR, if there is no PR yet. I'll try to find this
board on the systems I main
t(s) are on 12-CURRENT: ~ FreeBSD 12.0-CURRENT #38 r318285:
> Mon
> May 15 12:27:29 CEST 2017 amd64, customised kernels and "netmap" enabled (just
> for the record if that matters).
>
> In the past, I was able to revive the connection by simply putting the NIC
> down
&g
e connection by simply putting the NIC down
and then up again and while I had running a ping as a trace indication of the
state of the NIC, I got very often
ping: sendto: No buffer space available
Well, today I checked via dmesg the output to gather again those messages and
realised that the dmesg
6: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 tr
On Fri, Nov 1, 2013 at 8:32 AM, Matthias Apitz 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, thi
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
>> John Baldwin wrote:
> On Thursday, September 16, 2010 9:02:23 am Marcin Cieslak wrote:
>> Dnia 15.09.2010 John Baldwin napisał/a:
>> > On Monday, September 13, 2010 9:10:01 pm Marcin Cieslak wrote:
>> >> Output queue of tun(4) gets full after some time when sending lots of
>> >> data.
>> >> I
>> John Baldwin wrote:
> Oh, yes. I've updated the patch to remove D_NEEDGIANT.
So far (last 24 hours) my tun(4) with your patch was very stable.
I am updating it to remove D_NEEDGIANT. Thank you!
//Marcin
___
freebsd-current@freebsd.org mailing list
On Thursday, September 16, 2010 9:02:23 am Marcin Cieslak wrote:
> Dnia 15.09.2010 John Baldwin napisał/a:
> > On Monday, September 13, 2010 9:10:01 pm Marcin Cieslak wrote:
> >> Output queue of tun(4) gets full after some time when sending lots of data.
> >> I have been observing this on -CURRENT
Dnia 15.09.2010 John Baldwin napisał/a:
> On Monday, September 13, 2010 9:10:01 pm Marcin Cieslak wrote:
>> Output queue of tun(4) gets full after some time when sending lots of data.
>> I have been observing this on -CURRENT at least since March this year.
>>
>> Looks like it's a race condition
On Wednesday, September 15, 2010 5:57:34 pm Marcin Cieslak wrote:
> Dnia 15.09.2010 John Baldwin napisał/a:
> > On Monday, September 13, 2010 9:10:01 pm Marcin Cieslak wrote:
> >> Output queue of tun(4) gets full after some time when sending lots of data.
> >> I have been observing this on -CURREN
Dnia 15.09.2010 John Baldwin napisał/a:
> On Monday, September 13, 2010 9:10:01 pm Marcin Cieslak wrote:
>> Output queue of tun(4) gets full after some time when sending lots of data.
>> I have been observing this on -CURRENT at least since March this year.
>>
>> Looks like it's a race condition
On Monday, September 13, 2010 9:10:01 pm Marcin Cieslak wrote:
> Output queue of tun(4) gets full after some time when sending lots of data.
> I have been observing this on -CURRENT at least since March this year.
>
> Looks like it's a race condition (same in tun(4) and tap(4)),
> the following p
Output queue of tun(4) gets full after some time when sending lots of data.
I have been observing this on -CURRENT at least since March this year.
Looks like it's a race condition (same in tun(4) and tap(4)),
the following patch seems to address the issue:
Index: if_tap.c
===
r (arg=0x8055944) at ../common/tun.c:185
#3 0x2809e244 in pthread_getprio () from /lib/libthr.so.3
#4 0x in ?? ()
tun.c:185:
n = read(tun_fd, buf, sizeof(buf));
When the tunnel is "hung" ping6 packets to the other
tunnel end do not go out and after a while:
IP btw -,
ppp breaks down and the link doesn't come up by itself.
Pinging then to some known address I'm getting
no buffer space available
and if I wouldn't now reboot the machine it would probably never
get online again.
What is the problem with this buffer space leak?
--
Ch
Shizuka Kudo wrote:
> Thanks for your response. I wonder if I misunderstand
> your advice. When looking at the if_rl.c (dated Dec
> 14), there's already a timer attached to
> ifp->if_watchdog. Is this the timer you referred to?
> If so, it looks like this timer never called by the
> driver in my c
eral replies, but none worked
> in
> > my case.
> >
> > I have a Thinkpad 600X with a Melco cardbus 10/100
> > ethernet card (a Realtek 8139B) running 5.0
> NEWCARD
> > kernel with NMBCLUSTERS=16384.
> > "No buffer space available" occurred when I t
d (a Realtek 8139B) running 5.0 NEWCARD
> kernel with NMBCLUSTERS=16384.
> "No buffer space available" occurred when I tried to
> ftp a file in my Thinkpad from other client. "ifconfig
> rl0 down" and then "ifconfig rl0 up" resumed the
> operation for a
TERS=16384.
"No buffer space available" occurred when I tried to
ftp a file in my Thinkpad from other client. "ifconfig
rl0 down" and then "ifconfig rl0 up" resumed the
operation for awhile until the error happened again.
Setting media to 10baseT/UTP did not suffer f
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
> 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 "
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 +
> 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 sq
> >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 s
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.
>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,
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. Basical
On Mon, 18 Sep 2000, Ben Smithurst wrote:
> Does anyone have any clue what could cause errors like this? I've
> been seeing this sort of stuff since the SMPng commit, IIRC. I'm sure
> there's more information I should be giving, so just let me know what
> to find. dmesg is at the end.
...
> ep0:
On Mon, 18 Sep 2000, Ben Smithurst wrote:
> Does anyone have any clue what could cause errors like this? I've
> been seeing this sort of stuff since the SMPng commit, IIRC. I'm sure
> there's more information I should be giving, so just let me know what to
> find. dmesg is at the end.
ed 17 times
Sep 18 07:56:10 lithium timed[27809]: /current/src/usr.sbin/timed/timed/acksend.c 110:
sendto 192.168.91.47: No buffer space available
Sep 18 07:56:11 lithium dhclient: send_packet: No buffer space available
Sep 18 07:56:29 lithium dhclient: send_packet: No buffer space available
On Wed, 10 Nov 1999, Doug Ambrisko wrote:
> On one out of 8 machines, I ran into this problem. My network is running
> at 100BaseTX. I noticed that ifconfig showed OACTIVE flag set and I
> was running in autosense mode. So I setup the media to 100BaseTX and now
> it works okay.
>
> My guess is
Bill Marquette writes:
| For the last week and a half or so I've been trying to track this down
| assuming it was a configuration error on my part or a problem with my
| ISP's DHCP configuration. After switching from a DEC 20141 chipset card
| to a 3com 3c905, I found I was still having problems
w got maxusers at 128 and NMBCLUSTERS
at 16384 (in fairly small increments to see where it would start working).
NBUF is also currently at 4096 again, raised over a period of two weeks at
a recommendation from a friend. I'm still getting the "No buffer space
available" messages
37 matches
Mail list logo