4 ms·

Kielhofner's response. http://blog.krisk.org/2013/02/packets-of-death-update.html http://blog.krisk.org/2013/02/packets-of-death-update.html I used to use "La

Kielhofner's response. http://blog.krisk.org/2013/02/packets-of-death-update.html http://blog.krisk.org/2013/02/packets-of-death-update.html I used to use "Lanner" gear for voip and these had embedded intel ethernets. I don't have any more of them to test, but I swear I've seen it on them as well. We suspected power supply problems because the link lights would just go dark every once in a blue moon and need a power cycle to set right, but then we were never be able to reproduce it.

gonzo 14y ago
We use Lanner gear for VoIP, and have never seen a problem.
- noonespecial 14y ago
  I think we only saw it on FW-7550's at the beginning of the production run (the ones with the "snout" fans on the CPU and no case fan).
jessaustin 14y ago
I am impressed by his original troubleshooting, but this followup seems impractical. Of his three suggestions, only the third (Intel providing improved board testing tools) even seems like it could possibly prevent this sort of problem. Asking for hardware-enforced "sane" behavior is like asking, "why doesn't my computer know I don't want my program to deadlock, segfault, or loop indefinitely?" That is, if the controller could do that then it would solve the Halting Problem. Improved drivers, his second suggestion, are always a good thing, but drivers only get patched to handle broken hardware in response to the discovery of broken hardware. There is no way to anticipate each particular way a NIC could possibly be broken ahead of time. The market demands controllers with flexible and expandable functionality. Board manufacturers use the EEPROM to specify exactly what behavior is required. If a particular manufacturer underestimates the importance of correctness and doesn't perform the code review and testing necessary to prevent a PoD, that isn't Intel's fault.
- viraptor 14y ago
  > "why doesn't my computer know I don't want my program to deadlock, segfault, or loop indefinitely?" For a device which can be checked from outside (second subsystem for device self-monitoring), this is actually possible to implement and fairly common. Watchdogs are often implemented to restart automatically when the device is completely unresponsive.
  - jessaustin 14y ago
    I could imagine a board manufacturer doing something like this for an expensive, low-volume NIC. I still don't see how Intel could help.
- mnarayan01 14y ago
  > That is, if the controller could do that then it would solve the Halting Problem The halting problem is actually decidable for limited-memory machines, though you need O(2^n) memory beyond the n-memory of the machine to actually decide it.
- kkielhofner 14y ago
  Kristian Kielhofner here - While I understand your analogy I don't think it's an accurate one. In fact, with the release of the successor to the 82574 Intel has already implemented some of the things I suggested: http://communities.intel.com/community/wired/blog/2012/10/18/i210-launch-announcement http://communities.intel.com/community/wired/blog/2012/10/18... Clearly they have learned from the various EEPROM issues on previous controllers (including the 82574) and implemented (among other things) EEPROM signing, which addresses some (most?) of my concerns about sane hardware behavior. Software drivers already do some basic EEPROM checks on this hardware (I know because I've had to tweak them); I'm simply suggesting these checks go a little further to verify the various EEPROM settings than could potentially result in a scenario like this one. When the effects are as significant as they are here I hope we can all agree: more sanity checking is a good thing.
  - noonespecial 14y ago

gonzo 14y ago

We use Lanner gear for VoIP, and have never seen a problem.

noonespecial 14y ago
I think we only saw it on FW-7550's at the beginning of the production run (the ones with the "snout" fans on the CPU and no case fan).

jessaustin 14y ago

I am impressed by his original troubleshooting, but this followup seems impractical. Of his three suggestions, only the third (Intel providing improved board testing tools) even seems like it could possibly prevent this sort of problem. Asking for hardware-enforced "sane" behavior is like asking, "why doesn't my computer know I don't want my program to deadlock, segfault, or loop indefinitely?" That is, if the controller could do that then it would solve the Halting Problem. Improved drivers, his second suggestion, are always a good thing, but drivers only get patched to handle broken hardware in response to the discovery of broken hardware. There is no way to anticipate each particular way a NIC could possibly be broken ahead of time. The market demands controllers with flexible and expandable functionality. Board manufacturers use the EEPROM to specify exactly what behavior is required. If a particular manufacturer underestimates the importance of correctness and doesn't perform the code review and testing necessary to prevent a PoD, that isn't Intel's fault.

viraptor 14y ago
> "why doesn't my computer know I don't want my program to deadlock, segfault, or loop indefinitely?" For a device which can be checked from outside (second subsystem for device self-monitoring), this is actually possible to implement and fairly common. Watchdogs are often implemented to restart automatically when the device is completely unresponsive.
- jessaustin 14y ago
  I could imagine a board manufacturer doing something like this for an expensive, low-volume NIC. I still don't see how Intel could help.
mnarayan01 14y ago
> That is, if the controller could do that then it would solve the Halting Problem The halting problem is actually decidable for limited-memory machines, though you need O(2^n) memory beyond the n-memory of the machine to actually decide it.
kkielhofner 14y ago
Kristian Kielhofner here - While I understand your analogy I don't think it's an accurate one. In fact, with the release of the successor to the 82574 Intel has already implemented some of the things I suggested: http://communities.intel.com/community/wired/blog/2012/10/18/i210-launch-announcement http://communities.intel.com/community/wired/blog/2012/10/18... Clearly they have learned from the various EEPROM issues on previous controllers (including the 82574) and implemented (among other things) EEPROM signing, which addresses some (most?) of my concerns about sane hardware behavior. Software drivers already do some basic EEPROM checks on this hardware (I know because I've had to tweak them); I'm simply suggesting these checks go a little further to verify the various EEPROM settings than could potentially result in a scenario like this one. When the effects are as significant as they are here I hope we can all agree: more sanity checking is a good thing.
- noonespecial 14y ago