去年买了个带两个Intel 82574L网卡的工控机做All in One，发现其中一个网卡经常会死，平均一个礼拜死一次，另一个网卡一直很健壮。
期间试过将该网卡从ESXI直通给OpenWRT、升级OpenWRT从使用专有驱动到使用内核驱动的新版本、修改EEPROM、关闭offload、更换网线、增加散热，均无法彻底避免。
遇到的内核日志大体就这几种：Detected Hardware Unit Hang、Reset adapter unexpectedly、NIC link is down。
出现后，需要给网卡完整的断掉再通电才能够恢复。期间异常断网给家人带来了无尽的麻烦，特别我我在外时，家里断网，需要我回家后重启OpenWRT才能恢复，就异常麻烦。
之前互联网上对该问题的讨论，大多也就是我尝试过的那些方法，就剩pcie_aspm=off的方法我没试过，据说一些人试了也没有效果。最近无意中从上面这张图中见到了一个词“死亡数据包”。中文互联网上的信息实在有限，于是上Google用关键词“82574L death packet”搜索了一下，发现原来别有洞天。
商用硬件供应商Star2Star的技术总监Kristian Kielhofner于2013年在自己的博客发文指出，Intel的82574L（可能还包括82583）网卡芯片存在漏洞，会被特定的数据包攻击导致系统崩溃，这就是所谓的”packet of death”（死亡数据包）漏洞。坏消息是这个漏洞是底层问题，用Linux、BSD或者Windows都无所谓，统统都中枪。
他先是发现客户手里的机器会莫名其妙崩溃，并且需要经过完整的电源循环才能恢复，并且这个过程没有任何的规律可言。于是他花了几个星期-150小时来研究这个问题，最终在一个经销商的热情帮助下，发现了复现的方法，并将问题的源头指向了这个网卡，并写了bash脚本，通过ethtool命令修改EEPROM来修复（可惜他并不愿意分享他的脚本，与后来Intel官方发布的关闭电源管理的修改EEPROM脚本或许是一样的？），并写了一篇博客完整的记录整个过程。之后他登上了Slashdot，并得到了大量关注，并成功引起了Intel的关注，Intel的工程师打电话给他进行了愉快的交流，并提供了一个内部工具供他测试，并发布了官方的statement（可惜已经访问不到了）。博客下面有来自全世界的一百多条的评论，甚至有来自博客中提到的一款开源工具的作者的评论（改开源工具后来让Kristian Kielhofner为他的工具背书）。这些评论者由于没有得到作者分享的脚本，在评论中各自分享自己的EEPROM，试图寻找规律。评论中也有人贴出了Intel官方提供的EEPROM修复脚本（或许就是作者与Intel合作的成果？），有评论者反馈通过该脚本成果修复了公司的机器，并且7个月没有遇到任何问题（至少我是无法通过这个方案解决）。
作者在更新中，还发布了一个开源软件，通过记录网卡崩溃前的100M流量，来排查网络问题。
接着发现还有人专门采访他并发文在WIRED上。这件事还引起了CloudFlare的网络工程师的兴趣，并评论道”Figuring out something as convoluted as that is not only incredibly rewarding and satisfying, but time consuming and frustrating as well.”
一个公司的CTO，保持了极强的技术能力而非ppt能力，通过个人的力量，耗费大量时间，发现了巨头的某一款产品的某一个具体缺陷，巨头没有回避，而是成功与其合作，推动了产品的迭代。这个过程中，无数工程师参与专业型讨论，成功解决的也会回来反馈。同时还有媒体人参与报道。这种纯纯的技术的工程师文化，着实单纯，blog和Slashdot上的几百条评论没有任何戾气（跟当今中文互联网氛围差异很大）
现代软硬件越来越复杂，即使的巨头投入巨量的人力物力研发测试，也难以避免产品出现缺陷，工业领域的现代软硬件的稳定性和复杂度失控问题也值得思考
”Life is too short to be spent debugging Intel parts.”
— Van Jacobson
