Wom*_*baT 10 networking linux debian
我有自己的家庭服务器，它充当互联网的网关（不知道它是否是最好的名称）。基本上它有两个以太网端口，一个连接到我的 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=offethtool -K eth0 gso off gro off tso offfixeep-82573-dspd.sh表示我的硬件与该修复程序或类似的东西不兼容我还能尝试什么？我已经为此浪费了一整天，互联网连接无法使用，每个人都需要在手机上使用自己的 LTE/3G 互联网来访问网络。
Debian 是此类服务器的糟糕选择吗？
tel*_*coM 11
ServerFault 中有一个问题还有两个潜在的修复：
正如那里提到的，您可能想尝试：
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 省电代码的等效更新，从而触发该错误。
英特尔为 82579V 芯片提供了特定的固件更新工具，甚至可以与集成在主板上的 NIC 一起使用。不幸的是，我认为更新工具必须在 Windows 中运行。