Risoluzione dei deadlock del timer di watchdog Ethernet

Ho un box Linux debian (Debian Squeeze) che si blocca ogni poche ore se eseguo uno script Python che annusa un'interfaccia ...

La traccia dello stack è allegata alla fine di questa domanda. In sostanza, ho un'interfaccia Ethernet Broadcom ( bnx2driver) che sembra morire quando inizio una sessione di sniffing e poi tenta di trasmettere un frame dalla stessa interfaccia.

Da quello che posso dire, un timer del watchdog del kernel sta scattando ...

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

Penso che ci sia un modo per controllare i timer del watchdog con ioctl(ref: EmbeddedFreak: come usare il watchdog di Linux ).

Domande (originale):

~~Come posso trovare quali timer watchdog controllano eth3? Punti bonus se puoi dirmi come modificare il timer o anche disabilitare il cane da guardia ...~~

Domande (revisionate):

Come posso evitare che il timer del watchdog Ethernet provochi problemi?

Traccia dello stack

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

— Mike Pennington
fonte

Qual è il tuo MTU?

— Nils,

Come hai saputo di chiedere? L'ho impostato manualmente su 9000 su questa interfaccia prima di eseguire l'annusamento; appena prima che lo script finisse, l'ho resettato a 1500. In effetti, dopo aver disabilitato la funzione sniffer nello script, ho visto un altro deadlock quando ho eseguito sudo ip link set mtu 1500 dev eth3lo script (mentre stava finendo). Hai qualche idea su come cambiare MTU sull'interfaccia?

— Mike Pennington,

@Nils, è molto probabile che questo sia un kernel PAE ... il processore è un quad core Dual-CPU x86-64

— Mike Pennington

Interessante. Sembra che Linux e OpenBSD abbiano più cose in comune di quanto pensassi.

— Nils,

A proposito - perché cambi l'MTU - stai annusando un portmirror in modalità trunk?

— Nils,

Ho letto una storia simile da GeNUA. La soluzione è stata quella di riavviare il driver di rete (OpenBSD). Su Linux questo si tradurrebbe in: ifdown eth3 && rmmod bnx2 && modprobe bnx2 && ifup eth3.

Il problema principale era un problema di codifica interno con puntatori su un sistema PAE in combinazione con il driver broadcom.

— Nils
fonte

Quando mi stai suggerendo esattamente di eseguire quei comandi? Solo dopo aver cambiato l'MTU?

— Mike Pennington,

@MikePennington Ho cambiato il link dalla mia risposta alla versione inglese. Leggi ... Penso che dovresti cambiarlo ogni 30 minuti.

— Nils,

Devo eseguirlo in produzione per alcuni giorni prima di poter accettare ... funziona, assegnerò anche una taglia. Questo è stato il mio calcio per due settimane

— Mike Pennington

Presumibilmente non dovrei vedere questo problema se la mia interfaccia MTU è predefinita (1500), giusto? Ho rimosso il codice che ha modificato il mio MTU, ma sto ancora vedendo i deadlock

— Mike Pennington

Tutte le tue interfacce sono dello stesso tipo? Guardali con ethtool -gforse puoi aumentare i buffer di ricezione o trasmissione per evitare questo problema.

— Nils,

Commentando il mio codice che ha chiamato ethtoolper modificare i buffer della scheda di rete, è stato interrotto l'intervento dei timer del watchdog sulla bnx2scheda.

Voglio ancora trovare una risposta alla domanda sui timer di watchdog, ma farò un'altra domanda

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

— Mike Pennington
fonte