watchdog timeout -- resetting | Intel Pro 1000 | nfs

[tco]

ich hatte bisher meinen home-fileserver über samba laufen und hatte bis dato keine probleme gehabt.
nachdem ich heute aber auf nfs umstellen wollte bekomme ich folgende kernelmeldung

/val/log/messages

Mar 10 22:25:41 ds9 kernel: em0: watchdog timeout -- resetting
Mar 10 22:25:41 ds9 kernel: em0: link state changed to DOWN
Mar 10 22:25:44 ds9 kernel: em0: link state changed to UP
Mar 10 22:27:26 ds9 kernel: em0: watchdog timeout -- resetting
Mar 10 22:27:26 ds9 kernel: em0: link state changed to DOWN
Mar 10 22:27:29 ds9 kernel: em0: link state changed to UP
Mar 10 22:27:44 ds9 kernel: em0: watchdog timeout -- resetting
Mar 10 22:27:44 ds9 kernel: em0: link state changed to DOWN
Mar 10 22:27:47 ds9 kernel: em0: link state changed to UP
Mar 10 22:29:58 ds9 kernel: em0: watchdog timeout -- resetting
Mar 10 22:29:58 ds9 kernel: em0: link state changed to DOWN
Mar 10 22:30:02 ds9 kernel: em0: link state changed to UP
Mar 10 22:30:26 ds9 kernel: em0: watchdog timeout -- resetting
Mar 10 22:30:26 ds9 kernel: em0: link state changed to DOWN
Mar 10 22:30:29 ds9 kernel: em0: link state changed to UP

dmesg

FreeBSD 6.2-RELEASE-p11
em0: <Intel(R) PRO/1000 Network Connection Version - 6.2.9>

ich hab mir alte logs durchgeschaut und das ganze ist erst aufgetaucht nachdem ich nfs zum laufen gebracht habe.

den fehler bekomme ich jetzt über samba aber auch.

muss ich von einem hardwaredefekt ausgehen oder kann das auch andere ursachen haben?

ich hab gelesen dass es wohl mal n bug gab mit den intel 1000. aber der muss wohl schon gefixt sein...?

 

[Endorphine]

Das bedeutet, dass die Karte nicht mehr reagiert und die CPU ihr einen Tritt verpasst hat, wieder was zu tun.

Ursachen gibt's vielfältige... Was für restliche Hardware hast du denn? dmesg -a und pciconv -lv könnte aufschlussreich sein.

Ich hab mit pro/1000 unter FreeBSD allerdings auch schon mit übler Hardware wie alten VIA-Chipsätzen (inkl. KT133A und berüchtigter VIA 686B mit PCI-Bugs und ohne echten Arbiter) keine Probleme gehabt.

 

[tco]

dmesg -a
pciconf -lv

ich finds halt komisch dass es erst im zusammenhang mit nfs aufkam.

kann es an meinem quasi nicht vorhandenen FQDN liegen? oder generell an einer netzwerkeinstellung?

 

[tco]

ok, ich weiss jetzt dass es weder an der netzwerkkarte noch am switch liegt.
kann es einfach sein dass mein NT zu schwach ist und es mir ausgerechnet meine netzwerkkarte 'ausschaltet'? ich hab da nämlich gerade mal 250 watt. aber uA vier platten

 

[j_t]

allerdings auch schon mit übler Hardware wie alten VIA-Chipsätzen (inkl. KT133A und berüchtigter VIA 686B

lol
So uebel waren diese Kombo nun wirklich nicht. Hatte im Serverbetrieb stets biblische Uptimes und Reboots nur fuer Updates.

 

[rMarkus]

Eine Generation der em(4) hat Probleme mit "Interrupt-Mitigation" und einen relativ kleinen Ringpuffer.

- Betroffen ist 82543, 82544 (Generation 3)
- Fehler behoben in 82540 & 82541 (Generation 4), 82545, 82546.
- Nicht betroffen mangels Interrupt-Moderation sind 82542 und 82543

Es gab damals von Intel ein Note bezüglich Linux, dass dort der Fehler scheinbar nicht umgangen werden konnet. Scheinbar konnte die Interrupt-Mitigation nicht abgeschaltet werden bzw. deren Auslöseparameter (Zeit, durchgesetzte Frames) nicht ausreichend verändert werden.

Siehe: http://www.bsdforen.de/showthread.php?t=8237

 

[Endorphine]

Der 82540EM gehört afaik zur vierten PRO/1000 Generation und sollte daher dieses Problem nicht mehr haben. Aber ich denke auch, dass es einen Versuch wert ist, mal an den sysctl-Knöpfen des Treibers zu drehen.

82540EM:

The Intel 82540EM integrates Intel's fourth generation Gigabit MAC design [...]

Und in der em(4)-Manpage ist folgendes zu finden:

hw.em.rx_int_delay
This value delays the generation of receive interrupts in units
of 1.024 microseconds. The default value is 0, since adapters
may hang with this feature being enabled.

hw.em.rx_abs_int_delay
If hw.em.rx_int_delay is non-zero, this tunable limits the maxi-
mum delay in which a receive interrupt is generated.

hw.em.tx_int_delay
This value delays the generation of transmit interrupts in units
of 1.024 microseconds. The default value is 64.

hw.em.tx_abs_int_delay
If hw.em.tx_int_delay is non-zero, this tunable limits the maxi-
mum delay in which a transmit interrupt is generated.

 

[rMarkus]

Hallo,

dann sollte diese em(4) nicht betroffen sein. Lediglich bei FreeBSD 5.3 (?) gab es mal Probleme mit allem em(4) und re(4), was aber die Ursache im Betriebssystem hatte.

Da die Probleme nur mit NFS auftreten, würde ich als nächsten Versuch mal eventuell bestehende Problematiken mit UDP abklappern.
Einige bge(4) haben z.B. Probleme mit UDP und TCP-Offloading, daher wuerde ich TCP-Offloading mal zum Test abschalten:


... etwa so:

ifconfig em0 -rxcsum -txcsum

 

[Endorphine]

Da die Probleme nur mit NFS auftreten, würde ich als nächsten Versuch mal eventuell bestehende Problematiken mit UDP abklappern.

Den NFS-Mount auf TCP umstellen mit "tcp" in den Mountoptionen in der fstab wäre vll. auch einen Versuch wert.

Einige bge(4) haben z.B. Probleme mit UDP und TCP-Offloading [...]

Oha, welche bge(4)-Controller haben denn Probleme und wie äußern sich die Probleme? Ich habe mit einigen BCM5750A1, FreeBSD 6.x und immer (default) aktivem rxcsum,txcsum bis jetzt noch keine Probleme bemerkt.

 

[rMarkus]

Zu den Problemen bei bge(4):

Bis etwa FreeBSD 5.4 wurde bei bge(4) nur TCP-offloading in eine Richtung unterstützt (ich glaube Empfangend). Das Sendende Offload war zwar vorhanden aber abgeschaltet, da die Hardware teilweise Fehler machte.
Ab 5.5 bzw. 6.x wurde das dann in beide Richtungen freigeschaltet, was zur Folge hat, dass einige Frame-Typen zumindest bei den bcm570x verworfen werden.

Hierzu sind z.B. WOL-Pakete zu nennen, die einfach verschluckt werden.
Außerdem zeigen sich diese Probleme auch bei "netstat -i" als verlorene Frames.

Ich find's richtig schade, wie Broadcom den damals schon nahezu perfekten Alton Tigon-Chip ( ti(4) ) zum Schlechteren weiterentwickelt hat.

 

[Endorphine]

Danke, ich werde das mal beobachten. Von den ti(4) war ich bis jetzt aber nicht so begeistert. Die em(4)-Karten sind irgendwie in der Praxis nach meiner Erfahrung problemloser, bei FreeBSD 5.x gab's aber mit den ti(4) regelmäßig watchdog timeouts...

 

[tco]

Da die Probleme nur mit NFS auftreten, würde ich als nächsten Versuch mal eventuell bestehende Problematiken mit UDP abklappern.

ne, nachdem ich das timeout bei nfs bekommen habe kommt es nun über samba auch...

Einige bge(4) haben z.B. Probleme mit UDP und TCP-Offloading, daher wuerde ich TCP-Offloading mal zum Test abschalten:
... etwa so:

ifconfig em0 -rxcsum -txcsum

werd ich trotzdem mal ausprobieren.

aber ich weiss jetzt dass es am board liegt. ich hab mal über ein anderes board gebootet und das timeout trat nicht mehr auf.

 

[actro]

Hat bei mir geholfen.
Ich hatte ebenfalls watchdog-timeouts mit vr0, allerdings nur über nfs, nicht über samba.
Auf Dauer ein wenig nervig, wenn man sein NAS per nfs einhängt..

 

[tco]

ich hatte dann die über samba auch wieder weg bekommen. aber NFS blieb.
jetzt werkelt ein anderes board in dem PC und alles ist wunderbar.
anscheinend doch etwas hardware-inkompatibilität...?