Newsgroup: it.comp.os.linux.sys
Titolo: eth transmit timed out: perché?

Salve a tutti.
Su un server Debian Lenny ho un problema con le due interfacce di rete 
integrate (è un assemblato, con una MB Supermicro, controller Intel 
82573E/L).
Circa 1-2 volte al giorno la connessione si interrompe per qualche 
minuto. La prima volta che questo accade dopo che il server è stato 
acceso, in syslog trovo qualcosa di questo tipo:
 
kernel: [240398.633851] NETDEV WATCHDOG: eth3: transmit timed out
kernel: [240398.655131] ------------[ cut here ]------------
kernel: [240398.677027] WARNING: at net/sched/sch_generic.c:222 
dev_watchdog+0x8f/0xdc()
kernel: [240398.700808] Modules linked in: nls_utf8 cifs nls_base rfcomm 
l2cap bluetooth nfsd lockd nfs_acl auth_rpcgss sunrpc exportfs battery 
ppdev parport_pc lp parport dm_snapshot dm_mirror dm_log dm_mod loop 
serio_raw pcspkr i2c_i801 psmouse i2c_core rng_core container i3000_edac 
shpchp pci_hotplug edac_core button evdev ext3 jbd mbcache raid1 md_mod 
sg sd_mod ide_cd_mod cdrom ata_piix ata_generic libata dock piix floppy 
uhci_hcd ehci_hcd ide_pci_generic ide_core usbcore arcmsr e1000e mptspi 
mptscsih mptbase scsi_transport_spi scsi_mod thermal processor fan 
thermal_sys [last unloaded: scsi_wait_scan]
kernel: [240398.831425] Pid: 5116, comm: munin-graph Not tainted 
2.6.26-2-686 #1
kernel: [240398.860071]  [<c0122653>] warn_on_slowpath+0x40/0x66
kernel: [240398.887004]  [<c0119137>] hrtick_start_fair+0x82/0x12c
kernel: [240398.913237]  [<c011fdfc>] check_preempt_wakeup+0xa6/0xc6
kernel: [240398.938995]  [<c011b733>] try_to_wake_up+0xe8/0xf1
kernel: [240398.964405]  [<c0131aad>] autoremove_wake_function+0xd/0x2d
kernel: [240398.990051]  [<c0118511>] __wake_up_common+0x2e/0x58
kernel: [240399.015674]  [<c011a6fb>] __wake_up+0x29/0x39
kernel: [240399.041076]  [<c012f21b>] insert_work+0x58/0x5c
kernel: [240399.067021]  [<c012f509>] __queue_work+0x1c/0x28
kernel: [240399.092193]  [<c012f564>] queue_work+0x33/0x3c
kernel: [240399.117716]  [<c0267521>] dev_watchdog+0x8f/0xdc
kernel: [240399.142588]  [<c0129794>] run_timer_softirq+0x11a/0x17c
kernel: [240399.168153]  [<c0267492>] dev_watchdog+0x0/0xdc
kernel: [240399.192495]  [<c01266ad>] __do_softirq+0x66/0xd3
kernel: [240399.216297]  [<c012675f>] do_softirq+0x45/0x53
kernel: [240399.240436]  [<c0126a16>] irq_exit+0x35/0x69
kernel: [240399.263993]  [<c0110299>] smp_apic_timer_interrupt+0x6b/0x76
kernel: [240399.287383]  [<c0104368>] apic_timer_interrupt+0x28/0x30
kernel: [240399.307018]  [<c02b0000>] quirk_amd_ide_mode+0x5e/0xb6
kernel: [240399.331055]  =======================
kernel: [240399.354733] ---[ end trace 436fc7e98075028a ]---
kernel: [240401.234219] eth3: Link is Up 100 Mbps Full Duplex, Flow 
Control: RX/TX
kernel: [240401.258675] eth3: 10/100 speed: disabling TSO
 
Le volte successive invece è più sintetico:
 
kernel: [321981.259667] NETDEV WATCHDOG: eth3: transmit timed out
kernel: [321983.118515] eth3: Link is Up 100 Mbps Full Duplex, Flow 
Control: RX/TX
kernel: [321983.143793] eth3: 10/100 speed: disabling TSO
 
La riga NETDEV WATCHDOG non è sempre presente.
 
Questo succede su entrambe le interfacce. La connessione al server si 
interrompe, ma entro un massimo di 10 minuti torna tutto a posto.
Da cosa può dipendere?
 
Nota: il server è in piedi da anni e non aveva mai avuto questo 
problema. Però di recente ho dovuto sostituire la scheda madre; ho preso 
lo stesso modello, ma la revisione è più recente, ha minime differenze. 
Il sistema, che prima usava solo la eth0, ha visto le nuove interfacce 
come eth2 e eth3.
 
Spero di poter escludere un difetto della scheda... Forse dovrei provare 
a riconfigurare qualcosa, se le interfacce di rete sono di diverso tipo 
rispetto a prima?
 
Grazie per qualsiasi info.
 
-- 
Ciao,
   Marco.

come eth2 e eth3.
 
Non so da cosa possa dipendere, ma so da cosa dipendeva la volta che e'
successo a me. Puo' darsi che il tuo caso sia simile, e un controllo si
fa presto e costa poco.
 
Sostanzialmente lo switch era collegato a un alimentatore che non aveva
la linea di terra messa bene, ed andava allegramente a terra attraverso
il cavo di rete. E di li' attraverso l'interfaccia di rete, la MB, e l'
alimentatore del PC.
 
Sono quasi sicuro che ci sia una mezza dozzina di RFC che dicono che la
cosa non si puo' fare e chi ci prova ha la mamma in controsterzo; pero'
quelle RFC non le avevano tradotte in taiwanese, e cosi' ogni tanto una
bottarella di extravoltaggio mandava in tilt il chippino Realtek.
 
Magari la tua mobo di prima reggeva meglio o aveva la eth isolata, e la
mobo attuale regge meno o e' piu' fiduciosa nel prossimo.
 
O magari e' il contrario, e il PC si mette a terra tramite il cavo.
 
Leonardo
 
-- 
Tell us whether you spy, in the light of the morn,
what saluted was fiercely at the fall of the past day:
whose pips and whose bands in the very heart of the fray
bravely floated from the bulwarks to which we were sworn?

 il cavo di rete. E di li' attraverso l'interfaccia di rete, la MB, e l'
 
Uhm uhm...
 
Grazie per la testimonianza.
In effetti non è un'ipotesi da scartare, perché talvolta mi è sembrato 
che in concomitanza con questo problema ci fossero noie anche sugli switch.
Certo sarebbe strano - o semplicemente sfiga cosmica - se le interfacce 
di rete di questa nuova MB fossero le uniche a risentire di problemi 
elettrici dello switch, fra tutte le macchine che sono collegate allo 
stesso apparecchio...
 
Proverò a controllare.
 
-- 
Ciao,
   Marco.

 kernel: [240398.677027] WARNING: at net/sched/sch_generic.c:222
Il warning si genera nel modulo sch_generic.c alla linea 222 del codice
il quale dovrebbe essere il responsabile della schedulazione di 
trasmissione
e ricezione dati/pacchetti (TCP?).
Tanto è che disabilita il TSO ( TCP segmentation offload (TSO))
Dovrebbe essere qualcosa inerente alla segmentazione pacchetti TCP.
Prova a cambiare valore con 1492 o disabilitala tu direttamente.
 
Comunque sia è ovvio che la gestione di questa scheda dal suo driver
sia differente dalla precedente.


 Prova a cambiare valore con 1492 o disabilitala tu direttamente.
 
Grazie, ma nel frattempo avevo controllato con ethtool e il TSO era già 
disabilitato.
 
Sto ancora tenendo sotto controllo la situazione, perché successivamente 
è successo spesso che gli utenti perdessero la connessione col server 
anche se nel syslog non compariva più alcun avviso di questo tipo.
 
Continuo a ritenere probabile una causa come quella ipotizzata da 
Leonardo, cioè un problema dello switch di rete. Ho cambiato un po' i 
cablaggi per verificare questa ipotesi e sto aspettando di vedere i 
risultati.
 
-- 
Ciao,
   Marco.


Sarà ma l'errore mi sembra tipicamente software .
Comunque il controllo lo hai fatto prima o dopo l'avviso di timed out?
 

 Comunque il controllo lo hai fatto prima o dopo l'avviso di timed out?
 
L'avevo fatto a macchina appena riavviata, quindi prima che si 
verificasse di nuovo il problema.
 
-- 
Ciao,
   Marco.