2.6.39カーネルドロップパケットを備えたDebian6.0システム、SandyBridgeハードウェア
最近、既存のDebianシステムを新しいハードウェア（Intel Sandy Bridgeマザーボード上で実行されるコアi3チップ）に移行しました。非常に奇妙な問題が発生しています。ルーターにpingを実行すると、パケットの約50％がドロップされます。
テストに時間を費やしましたが、ルーターではないことを確認できます。ルーターの同じイーサネットポートに接続している場合でも、複数の異なるマシンで正常に動作します。戻ってくるpingの待ち時間は非常に短く、1ミリ秒未満です。これは、部屋の向こう側にあるルーターから予想されるとおりです。
Debian安定版でカーネル2.6.39を使用しています（カーネルはバックポートから取得しました）。カーネルとそれを実行するために必要ないくつかの関連パッケージを除いて、システムは100％Debian6.0です。カーネルはネットワークハードウェアを検出し、起動時にe1000eドライバーをロードします。ログには何も奇妙なことはありません。
もう1つ、問題があるにもかかわらず、ネットワークはそれと呼べるなら「機能」します。私が言いたいのは、yahooとgoogleにも正常にpingできるということです。もちろん、これらの場合にもパケットの約50％が失われますが、一部のパケットはare戻ってきます。このルーターに接続されている他のデバイスはすべて正常に動作しています。同じルーターに接続されているマシンでこれを入力しています。
私は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どうやらこのチップではサポートされていませんか？代わりに使用する特別なIntelツールはありますか？
tcpdumpを見ると、物事はより厳しく見え始めました。一部のパケットが元に戻らないだけでなく、一部のパケットも元に戻らないout！
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は機能します...そうですか？
これは悪いハードウェアでしょうか？まさか...そうですか？
ため息....多分私は古いシステムに戻るべきです。
どうやらこの問題はすでにUbuntuの人々に知られています。 '日へそれを手に入れました！
手始めに：簡単な回避策。次のようにイーサネットを10mpbsに減速すると、システムを再び実行できます。
Sudo ethtool -s eth0 speed 10 autoneg off
（mii-toolはこのイーサネットチップでは機能しないことに注意してください）
私は実際にはまだ確認済みの修正を持っていませんが、明らかに誰も修正していません。この問題の性質は人々が知っておく必要があるものであるため、私はこの質問に答えることを選びました。
Ubuntuのバグレポートによると、これはハードウェアの障害であり、ランダムに影響を及ぼします一部のみ最近のIntelイーサネットチップ。一部のモデルではなく、特定のチップ。つまり、どれが良いのか、どれが悪いのかを判断する方法はありません。少なくとも、82579V（私のチップ）と82579LMが影響を受け、Ubuntuチームはそれらを確認しました。影響を受ける他のモデルの数を誰が知っていますか。
少なくとも問題の範囲が完全に理解されるまでは、Intelイーサネットチップを使用するマザーボードを避けるのが賢明かもしれません。
結局のところ、これは実際にはハードウェアのバグのようです。最新のIntelドライバーをダウンロード、コンパイル、およびインストールできるという噂があります。これには、永続的なソフトウェアの回避策が含まれています。ダウンロードは ここ です。コンパイルとインストールは読者の練習問題として残されています。
このソフトウェアの回避策とは何か、そしてそれが機能やパフォーマンスを永久に低下させるかどうかに興味があります。トレードオフがあるはずですよね？残念ながら、このマザーボードを返品期間内に返送する必要があったため、自分でこれを試すことができませんでした。
Ubuntuのバグレポートが見つかりました ここ および ここ 。素晴らしいUbuntuチームに感謝します！彼らは本当にLinuxハードウェアの互換性のために素晴らしいことをします。
これについて私が最も驚いたのは、私がこの問題に最初に遭遇したようだということです。上記のUbuntuバグレポートは、この記事の執筆時点でまだアクティブです。 no one Linux on Sandy Bridgeをまだ使用していますか？ 10/100ネットワークハードウェアを持って地球上に残されたのは私だけですか？おそらく最も可能性の高い理由は、Intelイーサネットハードウェアの問題が最近明らかになったということです。
-エリック