I was lucky enough to find a very patient and helpful reseller in the field to stay on the phone with me for three hours while I collected data. This customer location, for some reason or another, could predictably bring down the ethernet controller with voice traffic on their network.
Let me elaborate on that for a second. When I say “bring down” an ethernet controller I mean BRING DOWN an ethernet controller. The system and ethernet interfaces would appear fine and then after a random amount of traffic the interface would report a hardware error (lost communication with PHY) and lose link. Literally the link lights on the switch and interface would go out. It was dead.
Nothing but a power cycle would bring it back.
...
With even more testing I discovered this issue with every version of Linux I could find, FreeBSD, and even when the machine was powered up complaining about missing boot media! It’s in the hardware; the OS has nothing to do with it. Wow.
http://blog.krisk.org/2013/02/packets-of-death.html
http://blog.krisk.org/2013/02/packets-o ... pdate.html
Sehr spannend.
----------
EDIT
On Thursday, Intel confirmed Kielhofner’s findings but said the bug wasn’t its fault. The blame lies with the company that made Kielhofner’s motherboards, Taiwan’s Lex CompuTech. Even though the networking hardware is built by Intel, the bug is in the firmware that Lex ships with its motherboards. To be specific, Lex seems to have used the wrong version of the Electrically Erasable Programmable Read-Only Memory (EEPROM) software for the controller setup that it’s shipping.
http://www.wired.com/wiredenterprise/20 ... -of-death/
Ups.
ich werd mir das morgen mal raussuchen.
...