Debian 9で「eth0：検出されたハードウェアユニットのハング」を修正する方法
私はインターネットへのゲートウェイとして機能する自分のホームサーバーを持っています（それが最適な名前かどうかはわかりません）。基本的に2つのイーサネットポートがあり、1つはISPに接続され、もう1つはLANスイッチに接続されています。ルーティングとNATが正常に構成され、他のサービスの束。
最近、Ubuntu 14.04からDebian 9（新規、クリーンインストール）に移行し、以前の構成をゆっくりと復元しました。他のコンピューター/電話/テレビなどがインターネットにアクセスできるように基本的なネットワーク構成を作成しただけでかなり早い段階で立ち往生していますが、パケットの損失が多く、接続が数秒間ハングしているようです。ログを検査すると、これが得られました：
[ 212.088208] e1000e 0000:00:19.0 eth0: Detected Hardware Unit Hang:
TDH <69>
TDT <aa>
next_to_use <aa>
next_to_clean <69>
buffer_info[next_to_clean]:
time_stamp <ffffa7f6>
next_to_watch <69>
jiffies <ffffa9e8>
next_to_watch.status <0>
MAC Status <80083>
PHY Status <796d>
PHY 1000BASE-T Status <3800>
PHY Extended Status <3000>
PCI Status <10>
[ 214.072275] e1000e 0000:00:19.0 eth0: Detected Hardware Unit Hang:
TDH <69>
TDT <aa>
next_to_use <aa>
next_to_clean <69>
buffer_info[next_to_clean]:
time_stamp <ffffa7f6>
next_to_watch <69>
jiffies <ffffabd8>
next_to_watch.status <0>
MAC Status <80083>
PHY Status <796d>
PHY 1000BASE-T Status <3800>
PHY Extended Status <3000>
PCI Status <10>
[ 216.088094] e1000e 0000:00:19.0 eth0: Detected Hardware Unit Hang:
TDH <69>
TDT <aa>
next_to_use <aa>
next_to_clean <69>
buffer_info[next_to_clean]:
time_stamp <ffffa7f6>
next_to_watch <69>
jiffies <ffffadd0>
next_to_watch.status <0>
MAC Status <80083>
PHY Status <796d>
PHY 1000BASE-T Status <3800>
PHY Extended Status <3000>
PCI Status <10>
[ 218.071082] ------------[ cut here ]------------
[ 218.072129] WARNING: CPU: 0 PID: 0 at /build/linux-EAZfyE/linux-4.9.51/net/sched/sch_generic.c:316 dev_watchdog+0x22d/0x230
[ 218.073249] NETDEV WATCHDOG: eth0 (e1000e): transmit queue 0 timed out
[ 218.074368] Modules linked in: xt_conntrack iptable_filter ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul iTCO_wdt iTCO_vendor_support ghash_clmulni_intel intel_cstate intel_uncore intel_rapl_perf pcspkr i915 sg drm_kms_helper lpc_ich mei_me mfd_core drm ie31200_edac joydev evdev mei edac_core shpchp i2c_algo_bit battery video button ip_tables x_tables autofs4 ext4 crc16 jbd2 fscrypto ecb glue_helper lrw gf128mul ablk_helper cryptd aes_x86_64 mbcache raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c crc32c_generic raid0 multipath linear hid_generic usbhid hid
[ 218.078853] raid1 md_mod sd_mod crc32c_intel i2c_i801 ahci i2c_smbus libahci libata scsi_mod ehci_pci ehci_hcd xhci_pci xhci_hcd e1000e ptp usbcore pps_core usb_common fan thermal
[ 218.082049] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.9.0-4-AMD64 #1 Debian 4.9.51-1
[ 218.083772] Hardware name: /DQ77KB, BIOS KBQ7710H.86A.0051.2013.0329.1350 03/29/2013
[ 218.085468] 0000000000000000 ffffffffa7729974 ffff98909e203e20 0000000000000000
[ 218.087205] ffffffffa7476eae 0000000000000000 ffff98909e203e78 ffff989094e28000
[ 218.088980] 0000000000000000 ffff989094fb9c80 0000000000000001 ffffffffa7476f2f
[ 218.090766] Call Trace:
[ 218.092579] <IRQ>
[ 218.092597] [<ffffffffa7729974>] ? dump_stack+0x5c/0x78
[ 218.094413] [<ffffffffa7476eae>] ? __warn+0xbe/0xe0
[ 218.096268] [<ffffffffa7476f2f>] ? warn_slowpath_fmt+0x5f/0x80
[ 218.098133] [<ffffffffa74aed52>] ? enqueue_task_fair+0x82/0x940
[ 218.100024] [<ffffffffa792cb2d>] ? dev_watchdog+0x22d/0x230
[ 218.101909] [<ffffffffa792c900>] ? qdisc_rcu_free+0x40/0x40
[ 218.103860] [<ffffffffa74e4020>] ? call_timer_fn+0x30/0x110
[ 218.105766] [<ffffffffa74e4524>] ? run_timer_softirq+0x1d4/0x430
[ 218.107709] [<ffffffffa74f4ca0>] ? tick_sched_handle.isra.12+0x20/0x50
[ 218.109654] [<ffffffffa74f4d08>] ? tick_sched_timer+0x38/0x70
[ 218.111630] [<ffffffffa7a0b0d5>] ? __do_softirq+0x105/0x290
[ 218.113594] [<ffffffffa747cf8e>] ? irq_exit+0xae/0xb0
[ 218.115567] [<ffffffffa7a0aeee>] ? smp_apic_timer_interrupt+0x3e/0x50
[ 218.117536] [<ffffffffa7a0a202>] ? apic_timer_interrupt+0x82/0x90
[ 218.119509] <EOI>
[ 218.119527] [<ffffffffa78cd31a>] ? cpuidle_enter_state+0x11a/0x2b0
[ 218.121505] [<ffffffffa74b9634>] ? cpu_startup_entry+0x154/0x240
[ 218.123486] [<ffffffffa8138f57>] ? start_kernel+0x443/0x463
[ 218.125426] [<ffffffffa8138120>] ? early_idt_handler_array+0x120/0x120
[ 218.127400] [<ffffffffa8138408>] ? x86_64_start_kernel+0x14c/0x170
[ 218.129384] ---[ end trace 6cd1142bfcc66b87 ]---
[ 218.131367] e1000e 0000:00:19.0 eth0: Reset adapter unexpectedly
[ 222.052843] e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx
私はこの質問を見つけました： e1000eアダプターを予期せずリセット/ハードウェアユニットのハングを検出 これは同じ問題のようですが、見つかった修正はどれもうまくいきませんでした。
私は試した：
- カーネルを
pcie_aspm=offで起動する - 奇妙なオプションをオフにする：
ethtool -K eth0 gso off gro off tso off - BIOSでASPMを無効化
- BIOSの省電力機能を無効にしました
- 使用されたスクリプト
fixeep-82573-dspd.shは、私のハードウェアがその修正またはそのようなものと互換性がないことを示しています - インテルのWebサイトからコンパイルされた最新のドライバー
他に何ができますか？私はすでにこれで丸一日失われました、インターネット接続は使用できません、誰もがウェブにアクセスするために電話で自分のLTE/3Gインターネットを使用する必要があります。
Debianはそのようなサーバーに悪い選択ですか？
ServerFaultには、さらに2つの潜在的な修正がある質問があります。
そこに述べられているように、あなたは試してみたいかもしれません：
- bIOS設定で拡張C1省電力状態（C1E）を無効にする、または
- TCP
ethtool -K eth0 tx off rx offによるオフロードチェックサムの無効化
バックアップからe1000e.koカーネルモジュールを抽出できる場合は、そのモジュールでmodinfoコマンドを使用してドライバーバージョンを一覧表示できます。
NICファームウェア更新の可能性を識別するには、正確なNICモデルを正確に識別する必要があります。ログ出力から、NICはPCIデバイス00：19.0であり、ネットワークインターフェイスの名前はeth0であることがわかります。これらのコマンドをrootとして実行してください：
# lspci -nn -s 00:19.0 -v
# ethtool -i eth0
最初のコマンドはNICのPCI ID番号を示し、2番目のコマンドはNICファームウェアバージョン番号を出力に含めます。
NICがIntel 82579V（PCI ID 8086：1503）の場合、省電力状態に関連する既知のバグがあり、Windows 8以降（つまり、最新のハードウェアのより高度な省電力状態を使用するのに十分新しいです）。 Ubuntu 14.04からDebian 9に更新すると、Linuxの省電力コードに同等の更新が行われ、バグがトリガーされる可能性があります。
Intelには、マザーボードに統合されたNICでさえ使用できる82579Vチップ用の特定のファームウェア更新ツールがあります。残念ながら、更新ツールはWindowsで実行する必要があると思います。
NIC間のケーブルと設定を切り替えることで問題が解決しました。したがって、eth0はLAN側のデバイスであり、eth1はインターネット側のデバイスでした。スイッチeth0がインターネットデバイスになり、eth1 LANが1になった後。理由と方法はわかりませんが、機能しているだけです。数時間後の高負荷下でも、すべて問題ありません。初期構成に戻すと、2分以内にドライバーがクラッシュします。
これが発生する理由を完全に見つけることはできませんが、まあ...今は良いです。