Hi all

I'm getting random loss of connectivity from my box - FC6 with 2.6.18.1 kernel version. I set up a constant ping and at the tims when my connection goes down I see the above message in the ping sequence.

64 bytes from 85.10.213.103: icmp_seq=360 ttl=242 time=1072 ms
64 bytes from 85.10.213.103: icmp_seq=361 ttl=242 time=1170 ms
64 bytes from 85.10.213.103: icmp_seq=362 ttl=242 time=1078 ms
64 bytes from 85.10.213.103: icmp_seq=363 ttl=242 time=958 ms
64 bytes from 85.10.213.103: icmp_seq=364 ttl=242 time=1125 ms
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available

I've already done this to attempt to increase by buffer space:

echo 98886080 > /proc/sys/net/core/wmem_max
echo 98886080 > /proc/sys/net/core/rmem_max
echo 98886080 > /proc/sys/net/core/wmem_default
echo 98886080 > /proc/sys/net/core/rmem_default

This seems to sometimes make the time between failures increase, other times it seems to have no effect at all.

How can I fix this

ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available

issue? IS it fixable at all? I've been googling this for several days, but nobody seems to be able to solve this once it crops up - several posts about it just deadend.

Which buffer is being referred to? How can I make this buffer bigger? Is it something else wrong somewhere (i. e. the buffer is not flushing when it should?)

ANY help appreciated!

Thanks

Check your /var/log/messages for NETDEV messages. If you are seeing them, and you are using the skge network driver, you need to boot with acpi=off.

Hi

Thanks for replying. My /var/log/messages looks like this:

[root@StefanLinux ~]# cat /var/log/messages
Dec 24 04:02:24 StefanLinux syslogd 1.4.1: restart.
Dec 24 08:49:10 StefanLinux gconfd (rylan-19650): starting (version 2.14.0), pid 19650 user 'rylan'
Dec 24 08:49:10 StefanLinux gconfd (rylan-19650): Resolved address "xml:readonly:/etc/gconf/gconf.xml.mandatory" to a read-only configuration source at position 0
Dec 24 08:49:10 StefanLinux gconfd (rylan-19650): Resolved address "xml:readwrite:/home/rylan/.gconf" to a writable configuration source at position 1
Dec 24 08:49:10 StefanLinux gconfd (rylan-19650): Resolved address "xml:readonly:/etc/gconf/gconf.xml.defaults" to a read-only configuration source at position 2
[root@StefanLinux ~]#

No NETDEV messages - but the log looks WAY too short - my system has been up for a few days. Could something be wrong with my syslogd as well?

I've tried passing acpi=off to the kernel on boot in GRUB, it has zero effect on the regularly collapsing eth0 interface problem I'm having...

Thanks anyway!

Hi guys

Just thought I'd report that it seems I've got this mitigated further or maybe licked in total!

It seems the buffer overflows I was experiencing was caused by a too long transmission queue length. I've changed the transmission queue length to 500 instead of the default 1000 by doing:

/sbin/ifconfig eth0 169.254.255.20 netmask 255.255.255.0 broadcast 169.254.255.255 txqueuelen 500 up

Now, if I run ifconfig I no longer have dropped packets:

eth0 Link encap:Ethernet HWaddr 00:16:E6:5D:F3:65
inet addr:169.254.255.20 Bcast:169.254.255.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1701246 errors:0 dropped:0 overruns:0 frame:0
TX packets:1135670 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:2447542857 (2.2 GiB) TX bytes:100667936 (96.0 MiB)
Interrupt:177 Base address:0x9000

Previously I had dropped packets indicated with a queue length of 1000. For the record, this is on a Gigabyte GA945PL-S3 motherboard with FC6 with a custom compiled 2.6.18.1 kernel with the

03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01)

NIC as indicated by lspci. I'm running the RealTek Linux driver for this card.

I further also massively increased certain buffersizes that were autotuned by the kernel. I've not tested if the queue length was the deciding factor (it works, so I want to leave it as it is!) but I also did this:

echo 98886080 > /proc/sys/net/core/wmem_max
echo 98886080 > /proc/sys/net/core/rmem_max
echo 98886080 > /proc/sys/net/core/wmem_default
echo 98886080 > /proc/sys/net/core/rmem_default
echo 32767 > /proc/sys/net/core/optmem_max
echo 256 > /proc/sys/net/core/somaxconn
echo 2000 > /proc/sys/net/core/netdev_max_backlog

echo 0 > /proc/sys/net/ipv4/tcp_timestamps
echo 1 > /proc/sys/net/ipv4/tcp_sack
echo 1 > /proc/sys/net/ipv4/tcp_window_scaling

echo 26244 786432 1048576 > /proc/sys/net/ipv4/tcp_mem
echo 43960 4194304 8194304 > /proc/sys/net/ipv4/tcp_rmem
echo 43960 4194304 8194304 > /proc/sys/net/ipv4/tcp_wmem

Hope this helps somebody else?

NOT Solved

Its doing it again...

Getting desperate. Anyhow...

Ok, gave up trying to get the 8168B/8111 gigabit NIC on the GA-945PL-S3 motherboard to work with Linux. The Realtek driver seems buggy, and causes a ENOBUFS network failure after very short usage periods in the kernel.

I disabled this onboard NIC in the BIOS on my GA-945PL-S3, and put in an older Realtek RTL-8139 NIC in a PCI slot. Everything is working fine now. I'm using the stock RTL-8139 NIC driver in the 2.6.18.1 kernel.

I think the Realtek 8168B/8111 will be unusable with this kernel and motherboard until realtek bugfixes it and releases a new version. The version that is NOT working with the RTL-8168B/81111 gigabit NIC on the GA-945PL-S3 motherboard is r1000v5.tgz from the realtek drivers page.

Ok, Realtek have provided me with a new driver with the filename

r8168-8.000.05.tar.bz2

when I complained about not being able to get the onboard NIC working on the GA-945PL-S3. I havent been able to test it yet, but anybody who has the same problems as me see if you can get this driver off the Realtek site. However, if you cannot find it, drop me a mail at spamnot@<removethis>polard.com and I'll be more than happy to mail this apparently updated driver to for the onboard NIC on the GA-945PL-S3 for Linux to you.