私は最近、既存のDebianシステムをIntel Sandybridgeマザーボード上で動作するコアi3チップである新しいハードウェアに移行しました。非常に奇妙な問題に密着しました。ルータでpingを実行すると、パケットの約50％が破棄されます。
テストに時間を費やし、ルーターではないことを確認できます。ルータの同じイーサネットポートに接続しても、複数の異なるコンピュータで正常に動作します。返されたping待ち時間は、部屋の反対側にあるルーターで予想されるように、1ミリ秒未満と非常に低かった。
私はDebian stableでカーネル2.6.39を使用しています（バックポートからカーネルを取得しました）。システムは、実行に必要なカーネルといくつかの関連パッケージを除いて100％Debian 6.0です。カーネルはネットワークハードウェアを検出し、起動時にe1000eドライバをロードします。ログには奇妙なことはありません。
もう一つのことは、問題にもかかわらずネットワークが「動作」していることです（そうすることができる場合）。私の言葉はYahooとGoogleにもうまくpingを送ることができるという意味です。もちろん、この場合はパケットの約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
試しましたが役に立ちませんでした：
より良いファームウェアが利用可能な場合は、Installを使用しますlinux-firmware-free（linux-firmware-nonfree使用できない場合、または少なくともカーネルが見つからない場合）。
BIOSでaspmを使用すると、aspmがe1000eイーサネットに問題を引き起こすことを報告した人もいます（役に立たない）。
問題が発生した場合は、カーネルで完全に無効にします。pcie_aspm（そうではありませんが、無効にすると新しい問題が発生します。）
mii-toolこのチップがサポートしていないと思いますか？代わりに使用できる特別なIntelツールはありますか？
私が見ると、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ユーザーに既に知られています。彼らに与える必要があります！
まず、問題をすばやく解決してください。次のようにイーサネット速度を10mpbsに下げると、システムを再実行できます。
sudo ethtool -s eth0 speed 10 autoneg off
（mii-toolはこのイーサネットチップでは機能しません。）
実際、まだ確定した修正は得られませんでしたが、明らかに誰も確認できませんでした。私がこの質問に答えることにした理由は、質問の本質が人々が知る必要があるからです。
Ubuntuのバグレポートによると、これはランダム効果のあるハードウェア障害です。一部のみ最新のインテルイーサネットチップ。特定のモデルではなく、特定のチップです。つまり、どれが良く、どちらが悪いかを知る方法がありません。 Ubuntuチームは、少なくとも82579V（マイチップ）と82579LMが影響を受けることを確認しました。どのように多くの他のモデルが影響を受けるか誰が知っていますか？
少なくとも問題の程度が完全に理解されるまで、Intel Ethernetチップを使用するマザーボードを避けるのが賢明かもしれません。
結局のところ、これはハードウェアエラーのようです。永続的なソフトウェア回避策を含む最新のIntelドライバをダウンロード、コンパイル、インストールできるという噂があります。ダウンロードしたアイテムは次のとおりです。ここ、編集およびインストールは、読者の練習問題として残されます。
私はこのソフトウェアの回避策が何であるか、機能やパフォーマンスが永久に低下するかどうか疑問に思います。少し妥協が必要です。そうですか？残念ながら、返品期間内にこのマザーボードを返品する必要があるため、自分で試してみることはできません。
Ubuntuのバグレポートを発見ここそしてここ。素晴らしいUbuntuチームに感謝します！彼らは実際にLinuxハードウェア互換性のために多くの素晴らしい仕事をしています。
私を最も驚かせたのは、明らかに私がこの問題に初めて触れた人の一人であるという事実でした。この記事を書いている時点で、上記のUbuntuバグレポートはまだ有効です。はい誰もSandy BridgeでLinuxを使用していますか？私は地球上で10/100ネットワークハードウェアを持つ唯一の人ですか？おそらく最も可能性の高い原因は、最近明らかになったIntelイーサネットハードウェアの問題です。
——エリック