解决以太网看门狗定时器死锁

我有一个debian linux框（Debian Squeeze），如果我运行嗅探接口的python脚本，则每隔几个小时就会死锁...

堆栈跟踪附加到此问题的底部。本质上，我有一个Broadcom以太网接口（bnx2驱动程序），当我开始嗅探会话然后尝试从同一接口发送帧时，该接口似乎消失了。

据我所知，内核看门狗定时器正在跳闸...

NETDEV WATCHDOG: eth3 (bnx2): transmit queue 0 timed out

我认为有一种方法可以控制看门狗定时器ioctl（参考：EmbeddedFreak：如何使用linux watchdog）。

问题（原文）：

~~我如何找到哪个看门狗定时器正在控制eth3？奖励积分，如果您可以告诉我如何更改计时器甚至禁用看门狗...~~

问题（修订）：

如何防止以太网看门狗定时器引起问题？

堆栈跟踪

Apr 30 08:38:44 Hotcoffee kernel: [275460.837147] ------------[ cut here ]------------
Apr 30 08:38:44 Hotcoffee kernel: [275460.837166] WARNING: at /build/buildd-linux-2.6_2.6.32-41squeeze2-amd64-NDo8b7/linux-2.6-2.6.32/debian/build/source_amd64_none/net/sched/sch_generic.c:261 dev_watchdog+0xe2/0x194()
Apr 30 08:38:44 Hotcoffee kernel: [275460.837169] Hardware name: PowerEdge R710
Apr 30 08:38:44 Hotcoffee kernel: [275460.837171] NETDEV WATCHDOG: eth3 (bnx2): transmit queue 0 timed out
Apr 30 08:38:44 Hotcoffee kernel: [275460.837172] Modules linked in: 8021q garp stp parport_pc ppdev lp parport pci_stub vboxpci vboxnetadp vboxnetflt vboxdrv ext2 loop psmouse power_meter button dcdbas evdev pcspkr processor serio_raw ext4 mbcache jbd2 crc16 sg sr_mod cdrom ses ata_generic sd_mod usbhid hid crc_t10dif enclosure uhci_hcd ehci_hcd megaraid_sas ata_piix thermal libata usbcore nls_base scsi_mod bnx2 thermal_sys [last unloaded: scsi_wait_scan]
Apr 30 08:38:44 Hotcoffee kernel: [275460.837202] Pid: 0, comm: swapper Not tainted 2.6.32-5-amd64 #1
Apr 30 08:38:44 Hotcoffee kernel: [275460.837204] Call Trace:
Apr 30 08:38:44 Hotcoffee kernel: [275460.837206]  <IRQ>  [<ffffffff81263086>] ? dev_watchdog+0xe2/0x194
Apr 30 08:38:44 Hotcoffee kernel: [275460.837211]  [<ffffffff81263086>] ? dev_watchdog+0xe2/0x194
Apr 30 08:38:44 Hotcoffee kernel: [275460.837217]  [<ffffffff8104df9c>] ? warn_slowpath_common+0x77/0xa3
Apr 30 08:38:44 Hotcoffee kernel: [275460.837220]  [<ffffffff81262fa4>] ? dev_watchdog+0x0/0x194
Apr 30 08:38:44 Hotcoffee kernel: [275460.837223]  [<ffffffff8104e024>] ? warn_slowpath_fmt+0x51/0x59
Apr 30 08:38:44 Hotcoffee kernel: [275460.837228]  [<ffffffff8104a4ba>] ? try_to_wake_up+0x289/0x29b
Apr 30 08:38:44 Hotcoffee kernel: [275460.837231]  [<ffffffff81262f78>] ? netif_tx_lock+0x3d/0x69
Apr 30 08:38:44 Hotcoffee kernel: [275460.837237]  [<ffffffff8124dda3>] ? netdev_drivername+0x3b/0x40
Apr 30 08:38:44 Hotcoffee kernel: [275460.837240]  [<ffffffff81263086>] ? dev_watchdog+0xe2/0x194
Apr 30 08:38:44 Hotcoffee kernel: [275460.837242]  [<ffffffff8103fa2a>] ? __wake_up+0x30/0x44
Apr 30 08:38:44 Hotcoffee kernel: [275460.837249]  [<ffffffff8105a71b>] ? run_timer_softirq+0x1c9/0x268
Apr 30 08:38:44 Hotcoffee kernel: [275460.837252]  [<ffffffff81053dc7>] ? __do_softirq+0xdd/0x1a6
Apr 30 08:38:44 Hotcoffee kernel: [275460.837257]  [<ffffffff8102462a>] ? lapic_next_event+0x18/0x1d
Apr 30 08:38:44 Hotcoffee kernel: [275460.837262]  [<ffffffff81011cac>] ? call_softirq+0x1c/0x30
Apr 30 08:38:44 Hotcoffee kernel: [275460.837265]  [<ffffffff8101322b>] ? do_softirq+0x3f/0x7c
Apr 30 08:38:44 Hotcoffee kernel: [275460.837267]  [<ffffffff81053c37>] ? irq_exit+0x36/0x76
Apr 30 08:38:44 Hotcoffee kernel: [275460.837270]  [<ffffffff810250f8>] ? smp_apic_timer_interrupt+0x87/0x95
Apr 30 08:38:44 Hotcoffee kernel: [275460.837273]  [<ffffffff81011673>] ? apic_timer_interrupt+0x13/0x20
Apr 30 08:38:44 Hotcoffee kernel: [275460.837274]  <EOI>  [<ffffffffa01bc509>] ? acpi_idle_enter_bm+0x27d/0x2af [processor]
Apr 30 08:38:44 Hotcoffee kernel: [275460.837283]  [<ffffffffa01bc502>] ? acpi_idle_enter_bm+0x276/0x2af [processor]
Apr 30 08:38:44 Hotcoffee kernel: [275460.837289]  [<ffffffff8123a0ba>] ? cpuidle_idle_call+0x94/0xee
Apr 30 08:38:44 Hotcoffee kernel: [275460.837293]  [<ffffffff8100fe97>] ? cpu_idle+0xa2/0xda
Apr 30 08:38:44 Hotcoffee kernel: [275460.837297]  [<ffffffff8151c140>] ? early_idt_handler+0x0/0x71
Apr 30 08:38:44 Hotcoffee kernel: [275460.837301]  [<ffffffff8151ccdd>] ? start_kernel+0x3dc/0x3e8
Apr 30 08:38:44 Hotcoffee kernel: [275460.837304]  [<ffffffff8151c3b7>] ? x86_64_start_kernel+0xf9/0x106
Apr 30 08:38:44 Hotcoffee kernel: [275460.837306] ---[ end trace 92c65e52c9e327ec ]---

debian ethernet deadlock

— 迈克·彭宁顿
source

您的MTU是多少？

— 尼尔斯2012年

你怎么知道问的？我在运行嗅探之前在此接口上将其手动设置为9000；在脚本完成之前，我将其重置为1500。实际上，在禁用脚本中的嗅探器功能之后，当我sudo ip link set mtu 1500 dev eth3在脚本中运行时（因为正在完成），我看到了另一个死锁。您是否对更改接口上的MTU有任何想法？

— Mike Pennington

@Nils，很有可能这是一个PAE内核...处理器是双CPU四核x86-64

— Mike Pennington

有趣。Linux和OpenBSD似乎比我想象的要多。

— 尼尔斯2012年

顺便说一句-为什么更改MTU-您是否在中继模式下嗅探端口镜像？

— 尼尔斯2012年

我从GeNUA读过类似的故事。他们的解决方法是重新启动网络驱动程序（OpenBSD）。在Linux上，这将转换为： ifdown eth3 && rmmod bnx2 && modprobe bnx2 && ifup eth3。

核心问题是PAE系统上的指针与Broadcom驱动程序一起使用的内部编码问题。

— 尼尔斯
source

您究竟何时建议我运行这些命令？仅在更改MTU之后？

— Mike Pennington

@MikePennington我将答案的链接从英文更改为英文。阅读...我认为您应该每30分钟更改一次。

— 尼尔斯2012年

我需要在生产中运行几天，然后我才能接受...。这项工作有效，我也会颁发赏金。这已经踢了我两周了

— 迈克·彭宁顿

如果我的接口MTU是默认值（1500），大概应该看不到这个问题，对吗？我删除了修改MTU的代码，但仍然遇到僵局

— Mike Pennington 2012年

您所有的接口都属于同一类型吗？看看他们ethtool -g也许你可以提高接收或发送缓冲区，以避免这个问题。

— 尼尔斯2012年

注释掉我的要求ethtool修改NIC缓冲区的代码，以防止看门狗计时器跳闸bnx2。

我仍然想找到有关看门狗定时器的问题的答案，但是我会问另一个问题

def _linux_buffer_alloc(iface=None, rx_ring_buffers=768,
    netdev_max_backlog=30000):

    default_rx = 255
    default_rx_jumbo = 0
    default_netdev_max_backlog = 1000
    ## Set linux rx ring buffers (to prevent tcpdump 'dropped by intf' msg)
## FIXME: removing for now due to systematic deadlocks with the bnx2 driver
#    sample: ethtool -G eth3 rx 768
#    cmd = 'ethtool -G %s rx %s' % (iface, rx_ring_buffers)
#    p = Popen(cmd.split(' '), stdout=PIPE)
#    p.communicate(); time.sleep(0.15)
#    sample: ethtool -G eth3 rx-jumbo 0
#    cmd = 'ethtool -G %s rx-jumbo %s' % (iface, default_rx_jumbo)
#    p = Popen(cmd.split(' '), stdout=PIPE)
#    p.communicate(); time.sleep(0.15)
## /FIXME

— 迈克·彭宁顿
source