How to prevent ENOBUFS failures in eth0 interface
 

Hi

I'm getting the following (sometimes) when I continuously ping (I'm doing so because my interface goes down randomly):

ping: sendmsg: no buffer space available

which originates from ENOBUFS coming back due to

132 ENOBUFS No buffer space available
An operation on a transport endpoint or pipe was not performed because the system lacked sufficient buffer space or because a queue was full.

How can I allocate sufficient buffer space or make sure the queue does not become full...?

This is a severe problem as the box is currently unusable as a server (or for anything else network related) due to its interface going down randomly with the above error.

I've found that the only way to get the box talking again is to ifdown / ifup the eth0 interface with ifconfig - nothing else works.

How can I prevent ENOBUFS errors?

Thanks!

Hi guys

Make the queue shorter. See below:

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...

Failure
 

Ok, I've dropped trying to get the Realtek RTL-8168B/8111 based Gigabit NIC on my GA-PL945-S3 motherboard working with Linux. I've disabled it in the BIOS and put in an older RTL-8139 based PCI NIC. Everything is working fine now, so my kernel and network setup IS fine. It is most probably a buggy linux driver from Realtek for the RTL-8168B/8111 NIC used onboard on this motherboard.

NOTE TO ALL - the R100v5.tgz driver from Realtek for the RTL-8168B/8111 gigabet ethernet adapter does not seem to work for Linux for the 2.6.18.1 kernel on the GA-945PL-S3 motherboard... causes ENOBUFS error.