我最近将现有的 Debian 系统迁移到新硬件，即在 intel sandybridge 主板上运行的核心 i3 芯片。我遇到了一个非常奇怪的问题；当我 ping 路由器时，大约 50% 的数据包被丢弃。
我花了一些时间测试，可以验证它不是路由器。即使连接到路由器上的同一以太网端口，它也可以在多台不同的机器上正常工作。返回的 ping 延迟非常低，不到 1 毫秒，正如您对位于房间另一端的路由器所期望的那样。
我使用的是 Debian stable 上的内核 2.6.39（我从向后移植获得了内核）。除了内核和一些运行所需的相关软件包之外，该系统是 100% Debian 6.0。内核检测网络硬件并在启动时加载 e1000e 驱动程序。日志中并没有什么奇怪的地方。
另一件事：尽管存在问题，但网络“有效”（如果你可以这样称呼的话）。我的意思是我也可以成功 ping yahoo 和 google。当然，在这些情况下我也丢失了约 50% 的数据包，但有些数据包是回来了。连接到该路由器的其他设备均工作正常。我正在连接到同一路由器的机器上输入此内容。
我对 Linux 比较有经验，但不知道从哪里开始解决这个问题。我唯一能想到的就是路由器是 10/100，而不是千兆。显然这不应该导致这个问题，但也许它是相关的？ OTOH，我很确定最后一台机器也有千兆位以太网。它被插入同一路由器上的同一端口。
是的，我已经多次尝试重新启动路由器和机器。
我希望这里有人会有想法。
更新：@bdk 提出了一些好的建议...希望我有好消息！ :(
我尝试了更多的事情，但一无所获。我还从系统中获取了一些输出以包含在此处。
有时，当我尝试 ping 时，它根本找不到主机。如果我再试一次，它可以连接。我认为这只是第一次 ping 失败。 @bdk，失败似乎是间歇性的，至少我看不到任何模式。
这是 dmesg 的相关行，我是否错过了一些危险信号？
[ 1.171187] e1000e: Intel(R) PRO/1000 Network Driver - 1.3.10-k2
[ 1.171190] e1000e: Copyright(c) 1999 - 2011 Intel Corporation.
[ 1.171225] e1000e 0000:00:19.0: PCI INT A -> GSI 20 (level, low) -> IRQ 20
[ 1.171236] e1000e 0000:00:19.0: setting latency timer to 64
[ 1.171339] e1000e 0000:00:19.0: irq 42 for MSI/MSI-X
[ 1.460976] e1000e 0000:00:19.0: eth0: (PCI Express:2.5GB/s:Width x1) e0:69:95:dd:5d:d9
[ 1.460979] e1000e 0000:00:19.0: eth0: Intel(R) PRO/1000 Network Connection
[ 1.461015] e1000e 0000:00:19.0: eth0: MAC: 10, PHY: 11, PBA No: FFFFFF-0FF
[ 48.475222] e1000e 0000:00:19.0: irq 42 for MSI/MSI-X
[ 48.530979] e1000e 0000:00:19.0: irq 42 for MSI/MSI-X
[ 50.120859] e1000e: eth0 NIC Link is Up 100 Mbps Full Duplex, Flow Control: Rx/Tx
[ 50.120863] e1000e 0000:00:19.0: eth0: 10/100 speed: disabling TSO
我尝试过但没有帮助的事情：
安装linux-firmware-free，，linux-firmware-nonfree以防有更好的固件可用（没有，或者至少内核没有找到它）
在 BIOS 中使用 aspm，其他人报告 aspm 导致 e1000e 以太网出现问题（没有帮助）
在内核中完全禁用pcie_aspm，以防导致问题（事实并非如此，但禁用它确实会带来新问题）
mii-tool貌似这个芯片不支持？有没有特殊的英特尔工具可以替代？
当我看一看时tcpdump，事情开始看起来更加严峻。不仅有些数据包没有成功返回，有些甚至没有成功出去！
14:25:01.162331 IP debian.local > 74.125.224.80: ICMP echo request, id 2334, seq 1, length 64
14:25:02.168630 IP debian.local > 74.125.224.80: ICMP echo request, id 2334, seq 2, length 64
14:25:02.228192 IP 74.125.224.80 > debian.local: ICMP echo reply, id 2334, seq 2, length 64
14:25:07.236359 IP debian.local > 74.125.224.80: ICMP echo request, id 2334, seq 3, length 64
14:25:07.259431 IP 74.125.224.80 > debian.local: ICMP echo reply, id 2334, seq 3, length 64
14:25:31.307707 IP debian.local > 74.125.224.80: ICMP echo request, id 2334, seq 9, length 64
14:25:32.316628 IP debian.local > 74.125.224.80: ICMP echo request, id 2334, seq 10, length 64
14:25:33.324623 IP debian.local > 74.125.224.80: ICMP echo request, id 2334, seq 11, length 64
14:25:33.349896 IP 74.125.224.80 > debian.local: ICMP echo reply, id 2334, seq 11, length 64
14:25:43.368625 IP debian.local > 74.125.224.80: ICMP echo request, id 2334, seq 17, length 64
14:25:43.394590 IP 74.125.224.80 > debian.local: ICMP echo reply, id 2334, seq 17, length 64
14:26:18.518391 IP debian.local > 74.125.224.80: ICMP echo request, id 2334, seq 30, length 64
14:26:18.537866 IP 74.125.224.80 > debian.local: ICMP echo reply, id 2334, seq 30, length 64
14:26:19.519554 IP debian.local > 74.125.224.80: ICMP echo request, id 2334, seq 31, length 64
14:26:20.518588 IP debian.local > 74.125.224.80: ICMP echo request, id 2334, seq 32, length 64
14:26:21.518559 IP debian.local > 74.125.224.80: ICMP echo request, id 2334, seq 33, length 64
14:26:21.538623 IP 74.125.224.80 > debian.local: ICMP echo reply, id 2334, seq 33, length 64
14:26:37.573641 IP debian.local > 74.125.224.80: ICMP echo request, id 2334, seq 35, length 64
14:26:38.580648 IP debian.local > 74.125.224.80: ICMP echo request, id 2334, seq 36, length 64
14:26:38.602195 IP 74.125.224.80 > debian.local: ICMP echo reply, id 2334, seq 36, length 64
注意请求顺序，1、2、3...9？！那可不好。
我知道 Sandy Bridge 还比较新，但 Linux 确实可以工作......对吗？
这可能是硬件不好吗？不可能吧……对吧？
叹....也许我应该回到旧系统。
答案1
显然这个问题已经被 Ubuntu 的用户知道了。必须把它交给他们！
对于初学者来说：快速解决问题。您可以通过将以太网速度减慢至 10 mpbs 来让系统再次运行，如下所示：
sudo ethtool -s eth0 speed 10 autoneg off
（请注意，mii-tool 不适用于该以太网芯片）
实际上我还没有得到确认的修复，但显然没有人这样做。我选择回答这个问题，是因为这个问题的本质是人们需要意识到的。
根据 Ubuntu bug 报告，这是一个随机影响的硬件故障只有一些最近的英特尔以太网芯片。不是某些型号，而是某些芯片。这意味着无法区分哪些是好的，哪些是不好的。 Ubuntu 团队已经确认了至少 82579V（我的芯片）和 82579LM 受到影响。谁知道还有多少其他型号受到影响。
避免使用使用英特尔以太网芯片的主板可能是明智之举，至少在问题的严重程度得到充分了解之前是这样。
所以看来这毕竟是一个硬件错误。有传言称您可以下载、编译和安装最新的英特尔驱动程序，其中包含永久的软件解决方法。下载的是这里、编译和安装留给读者作为练习。
我很好奇这个软件的解决方法是什么，以及它是否会永久降低任何功能或性能。必须有一些权衡，对吧？不幸的是，我无法亲自尝试这个，因为我需要在退货窗口内退回这块主板。
Ubuntu bug 报告被发现这里和这里。非常感谢出色的 Ubuntu 团队！他们确实为 Linux 硬件兼容性做了很多伟大的事情。
最让我惊讶的是，我显然是最先遇到这个问题的人之一。截至撰写本文时，上述 Ubuntu 错误报告仍然有效。是没有人在 Sandy Bridge 上使用 Linux 了吗？我是这个星球上唯一拥有 10/100 网络硬件的人吗？也许最可能的原因是英特尔以太网硬件问题最近才显现出来。
——埃里克