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
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
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
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
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
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
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
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
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
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
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
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.
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:
>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,
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 s
> 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
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 "
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
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
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
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
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
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
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:
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
===
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
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 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
>> 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
>> 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
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
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
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
37 matches
Mail list logo
