There are services a kernel provides to user-space (such as opening sockets). There is a well-defined interface (API) that user-space programs can interact with the kernel through.
In this case, the user-space program is repeatedly opening sockets and sending file descriptors through them, then closing the sockets. These actions are performed by the kernel. It will hold the file descriptor in a buffer until the other end of the socket reads it. The particular bug is that a garbage collector should eventually free the file descriptor, but it doesn't - the fd gets leaked. The leaked fds add up and sit there consuming resources. Killing the program doesn't free the resources because they are not owned by the program.
Apparently this issue is already known to the Ubuntu folks. Got to hand it to 'em!
For starters: the quick work around. You can get your system running again by slowing down the ethernet to 10 mpbs like this:
sudo ethtool -s eth0 speed 10 autoneg off
(Note the mii-tool does NOT work with this ethernet chip)
I actually don't have a confirmed fix yet, but apparently no one does. I chose to answer this question because the nature of this problem is something people need to be aware of.
According to the Ubuntu bug report, this is a hardware fault that
randomly affects only some recent Intel ethernet chips. Not some
models, but certain chips. Meaning there's no way to tell which ones
are good and which aren't. At a minimum, the 82579V (my chip) and the
82579LM are affected, Ubuntu team has confirmed those. Who knows how
many other models are affected.
It may be wise to avoid motherboards that use Intel ethernet chips, at
least until the extent of the problem is fully understood.
So it appears this actually is a hardware bug, after all. There are rumors that you can download, compile, and install the latest intel driver, which contains a permanent software workaround. The download is here, compile and install are left as an exercise for the reader.
I'm curious what this software workaround is, and whether it permanently reduces any functionality or performance. There must be some tradeoff, right? Unfortunately I was unable to experiment with this myself, since I needed to get this motherboard sent back within the return window.
Ubuntu bug reports be found here and here. Many thanks to the awesome Ubuntu team! They really do great things for Linux hardware compatibility.
What surprised me most about this is that I was apparently among the first to come across this issue. The Ubuntu bug reports above are still active as of this writing. Is no one using Linux on Sandy Bridge yet? Am I the only person left on the planet with 10/100 network hardware? Perhaps the most likely reason is that the Intel ethernet hardware problem only recently manifested itself.
-- Eric
Best Answer
From the operating system's perspective, user space is the execution of code from a process, and kernel space is the execution of code from the kernel. A transition from user space to kernel space is the entry into a system call, and a transition from kernel space to user space is the return from a system call.
From the processor's perspective, user space and kernel space are privilege levels. “Ring 3” and “ring 0” are the names used on Intel x86 processors (there are rings 1 and 2, but most unices don't use them, because there isn't a lot of use for them). Other CPU types use different names, for example user mode and privileged (or system) modes on ARM.
Transition between modes is done by instructions that both change the processor mode and jump to a different address; the detail of these instructions is very much dependent on the CPU type. In addition to switching the processor mode and jumping to a different address, the mode transition instructions typically perform some other tasks such as swapping the value of a few registers (again, this is very CPU-dependent).
A transition from user mode to kernel mode has to jump to a fixed address, which has been set by the kernel. In order to maintain the security of the system, code in user mode cannot be allowed to switch the processor to kernel mode except to invoke a piece of code (the system call entry point) which has been specially crafted to work securely no matter what the user mode code has been doing. The system call entry point first saves register values into a designated memory area, and performs any other necessary bookkeeping, then it reads the system call parameters and dispatches the system call to the appropriate function. Depending on the processor type, the bookkeeping may involve setting the MMU tables appropriately. The kernel may decide at any point to pause the calling process and schedule another process.
A transition from kernel mode to user mode can happen anywhere the kernel deems fit. The kernel restores the saved registers, the MMU configuration and anything else that is necessary, and writes the system call's return value, and finally jumps back to the instruction in the process after the system call.