我有自己的家庭服务器，它充当互联网网关（不知道这是否是最佳名称）。基本上它有两个以太网端口，一个连接到我的 ISP，另一个连接到 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说我的硬件与该修复不兼容或类似的东西 - 从英特尔网站编译的最新驱动程序
我还能尝试什么？我已经为此浪费了一整天的时间，互联网连接无法使用，每个人都需要在手机上使用自己的 LTE/3G 互联网来访问网络。
Debian 对于这样的服务器来说是不是一个糟糕的选择？
答案1
ServerFault 中有一个问题，还有两个潜在的修复方法：
正如那里提到的，您可能想尝试：
- 在 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 号，第二个命令在其输出中包含 NIC 固件版本号。
如果 NIC 恰好是 Intel 82579V（PCI ID 8086:1503），则其中存在与省电状态相关的已知错误，这也会导致 Windows 8 及更高版本出现问题（即，操作系统足够新，可以使用现代硬件的更高级省电状态）。从 Ubuntu 14.04 更新到 Debian 9 可能会带来 Linux 省电代码的等效更新，从而导致触发该错误。
Intel 有一个专门针对 82579V 芯片的固件更新工具，甚至可以与主板上集成的 NIC 一起使用。不幸的是，我认为更新工具必须在 Windows 中运行。
答案2
问题通过以下方式解决...切换 NIC 之间的电缆和配置。因此，eth0 是 LAN 端设备，eth1 是 Internet 端设备。切换后，eth0 成为 Internet 设备，eth1 成为 LAN 设备。不知道为什么以及如何，但它确实在工作。即使在几个小时后负载过重的情况下，一切正常。当我将其切换回初始配置时，驱动程序在不到 2 分钟后就崩溃了。
我完全找不到发生这种情况的任何原因，但是好吧......现在很好。