NETDEV WATCHDOG: eth0: transmit timed out

[daemotron]

Heute abend ist mir mein Server unmotiviert abgeschmiert; der einzige Hinweis in der findet sich in /var/log/kern.log

Code: Select all

NETDEV WATCHDOG: eth0: transmit timed out
NETDEV WATCHDOG: eth0: transmit timed out
NETDEV WATCHDOG: eth0: transmit timed out

Die Kiste war grade (ok, schon seit heute morgen) mit einem rsync eines Gentoo Source Mirrors beschäftigt (und hat dabei natürlich schon ein paar GB durch's NIC gezogen).

Dr. Google hat mir verraten, dass es mit dem TCP Segmentation Offload zu tun haben könnte - bin mir aber nicht sicher, ob das wirklich die einzige Ursache ist, die dafür in Frage kommt (NIC ist ein Realtek RTL-8169 Gigabit Ethernet Adapter). Hab TSO jetzt jedenfalls erst mal deaktiviert.

Meine Fragen an Euch:

• Kommen noch weitere Ursachen für diesen Fehler in Frage?
• Gibt es einen Weg, das reproduzierbar zu testen? (ist mir bisher nicht gelungen)
• Gibt es einen eleganteren Weg, TSO zu deaktivieren, als das per init-Skript zu erledigen?
  EDIT Zumindest unter Gentoo hab ich eine Lösung gefunden - in der /etc/conf.d/net eine Funktion startup() einfügen, der wird beim Start jeden Interfaces der Interface-Name in der Variablen $IFACE übergeben - doch das nur am Rande...

[theomega]

Hy,
ist der Fehler wirklich durch das deaktivieren des Watchdogs behobe. Hatte genau das gleiche Problem auf einem Rootserver: Plötzlich kam der Fehler und alle Befehle haben nichts genutzt, selbst das dekativieren des Watchdogs nicht, immer der gleiche Fehler sobald Last auf dem Netzwerk (oder der CPU, das war nicht ganz klar zu unterscheiden) war.

Hast du es behoben bekommen?

gruß
TO

[ephigenie]

Hi - ich hatte in den letzten Tagen auch schwer damit zu kämpfen ...

versuch mal mit append = "noapic" zu booten...

[theomega]

Hy,
genau, richtig, ich habe alles ausprobiert (verschiedene Kernel-Versionen, diverse Netzwerkkarten) nichts hat geholfen, ausser den apic komplett zu deaktivieren. acpi dagegen scheint keinen einfluss darauf zu haben, obwohl der support das die ganze Zeit behaptet hat.

Was bei mir ganz komisch ist: Die Sache trat plötzlich auf, nichts an der Hardware wurde verändert. ganz komisch!

Wo habt ihr den euere Server? Beim berühmten Provider aus Nürnberg?

Gruß
TO

[daemotron]

Wo habt ihr den euere Server? Beim berühmten Provider aus Nürnberg?

Bingo... und mein Kernel (Marke Eigenbau) hat gar keine ACPI-Unterstützung eingebaut...

In der letzten Woche trat das Problem bei mir nicht mehr auf, allerdings war der Server auch nur mäßig belastet, was Netzwerk-I/O angeht. Ich habe allerdings nicht den Watchdog deaktiviert, sondern lediglich TSO für das betroffene NIC abgeschaltet. Ob das wirklich die Ursache war, wird sich allerdings erst beim nächsten NIC-Stresstest herausstellen (hab einen zweiten Server beim selben Provider, allerdings hab ich schon etliche GB zwischen den beiden hin und herkopiert, was nie zu einem "transmit timed out" geführt hat - von daher argwöhne ich, dass es eventuell auch an der Netzwerk-Infrastruktur liegen könnte).

Hier noch meine preup-Funktion, mit der ich TSO deaktiviere (Gentoo-User können sie einfach in ihre /etc/conf.d/net einfügen):

Code: Select all

preup() {
    ethtool -K ${IFACE} tso off
    return 0
}

[theomega]

Hy,
also bei mir hat wie gesagt an und abgeschaltetes ACPI wie gesagt überhaupt keinen Einfluss, momentan habe ich es auch garnicht einkompiliert (das Wiki vom Hoster sagt übrigends was ganz anderes, angeblich ist acpi sogar zwang, bei mir gehts auch ohne).

Auch mir ging es so: Ich konnte den Ausfall nicht wirklich reproduzieren, egal welche künstliche Last (von anderen Server usw) ich ausprobiert habe, nichts hat geholfe. Erst als wieder "normale" Last in form eines MySQL-Servers auf dem Server war kam es zu den Fehlern und zwar recht schnell (maximal 6 Stunden).

Bei mir haben die von dir genannten befehle rein garnichts gebracht, war immernoch das gleiche.

Tritt das Problem auch bei dir plötzlich auf? Oder haste den Server neu?

Gruß
TO

[daemotron]

Die Maschine läuft seit knapp einem halben Jahr, allerdings erst seit drei Monaten produktiv. Einen Zusammenhang mit MySQL hab ich bisher nicht feststellen können (was aber nicht heißen muss, dass er nicht existiert). Ich habe das Gefühl, dass ich die Fehler immer dann zu sehen bekomme, wenn größere Datentransfers per FTP (z. B. Backup) oder rsync laufen.

Interessanterweise scheint der Fehler bei mir zumindest immer mal wieder in Paarung mit I/O-Problemen in Richtung Disks aufzutreten - nämlich dann, wenn die Kiste tatsächlich abstürzt. Dann ist in den Logs nichts mehr zu finden, Binaries lassen sich nicht mehr ansprechen etc. - als hätte jemand den Stecker an der Platte gezogen (oder den Controller demoliert - ist ein 3ware 8006 mit 2 Platten in RAID1, dass beide defekt sind, halte ich für unwahrscheinlich). Von daher tippe ich auf ein Problem bei den entsprechenden Kernelmodulen (3w_xxxx und rtl_8169) oder bei deren gleichzeitiger Verwendung.

Ich habe einen baugleichen Server (auch mit derselben OS- und Softwarekonfiguration) beim selben Provider, nur ohne 3ware-Controller (aber dafür mit Software-RAID). Bei dem treten diese Fehler und Abstürze nicht auf. Von daher würde mich interessieren, ob Du auch einen Hardware-RAID-Controller eingebaut hast oder ob ich doch woanders nach der Ursache weiterforschen muss.

[Anonymous]

Interessanterweise scheint der Fehler bei mir zumindest immer mal wieder in Paarung mit I/O-Problemen in Richtung Disks aufzutreten - nämlich dann, wenn die Kiste tatsächlich abstürzt. Dann ist in den Logs nichts mehr zu finden, Binaries lassen sich nicht mehr ansprechen etc. - als hätte jemand den Stecker an der Platte gezogen (oder den Controller demoliert - ist ein 3ware 8006 mit 2 Platten in RAID1, dass beide defekt sind, halte ich für unwahrscheinlich). Von daher tippe ich auf ein Problem bei den entsprechenden Kernelmodulen (3w_xxxx und rtl_8169) oder bei deren gleichzeitiger Verwendung.

Ich hatte den "Spass" mit der Hardware-Kombination (vermutlich beim selben Provider) auch schon, schätze mal wir haben dieselbe Hardware. Ich habe allerdings Debian Etch verwendet. Mit dem 32-bit Image und div. Kerneln, selbstkompilierten Treibern von NIC und 3ware hat mich das System fast in den Wahnsinn getrieben. Eine Reinstallation mit dem Debian Etch 64bit-Image hat dann Wunder gewirkt - nicht wirklich erklärbar, aber im Ergebnis für mich OK.

Ist dein Rechner ein Dual-Core, wird also SMP im Kernel verwendet? Mir sind bisher nur Fälle mit SMP Systemen bekannt geworden.

Wobei ich im Zusammenhang mit *diesem* Verhalten die Watchdog Meldungen nicht hatte, die kamen aber massiv, als man auf Providerseite eine RTL-8139 100 MBit NIC in den Server gesteckt hatte, nicht aber mit der 8169er...

LG
Maik

[daemotron]

Ich hatte den "Spass" mit der Hardware-Kombination (vermutlich beim selben Provider) auch schon, schätze mal wir haben dieselbe Hardware.

Und ich dachte schon, ich bin zu d**f... habe aber leider feststellen müssen, dass dieser Provider beim Hardware verbauen recht willkürlich vorgeht - bei drei verschiedenen Servern (aber gleiches Produkt) drei verschiedene HW-Konfigurationen. Wahrscheinlich wird verschraubt, was grade rumliegt... :roll:

Eine Reinstallation mit dem Debian Etch 64bit-Image hat dann Wunder gewirkt - nicht wirklich erklärbar, aber im Ergebnis für mich OK.

Hmm, damit könnte ich mich nicht anfreunden - mit Debian hab ich nur ein kurzes Intermezzo gehabt, da bin ich nicht wirklich fit genug, um einen produktiven Server zu administrieren. Von meinem mühsam zusammengebauten und optimierten Gentoo will ich mich einfach nicht verabschieden 8) Außerdem mag ich bei nur 2 GB RAM eigentlich kein 64Bit-System draufhaben (ich könnte ja theoretisch Gentoo umbasteln und danach mal world emergen) - ich vermute auch eher, dass die Stabilisierung nicht aus den 64 Bit resultiert, sondern aus irgend einem anderen Unterschied zwischen 32- und 64-Bit Version.

Ist dein Rechner ein Dual-Core, wird also SMP im Kernel verwendet? Mir sind bisher nur Fälle mit SMP Systemen bekannt geworden.

Volltreffer, ist ein Athlon 64 X2 - natürlich habe ich daher SMP-Support für 2 CPUs in meinen Kernel eingebaut. Unterstützung für den RTL-8139 hab ich allerdings abgeklemmt (war ja auch nicht verbaut) - als einziges NIC wird der 8169 unterstützt (der laut Hotline onboard verbaut ist).

Interessant ist, dass ich seit dem letzten Kernel-Update an der Ecke Ruhe habe - ich hab die aktuellen hardend-sources (2.6.20-r2) von Gentoo genommen und ein bisschen umgemodelt (siehe Parallel-Thread). Außerdem hab ich TSO nach wie vor deaktiviert, und seit dem habe ich weder Abstürze durch I/O-Probleme gehabt noch irgendwelche transmit timeouts.

[daemotron]

Zu früh gefreut - heute hat er wieder zugeschlagen, der

Code: Select all

NETDEV WATCHDOG: eth0: transmit timed out

Und zwar massiv wie nie... gleich drei Server-Abstürze an einem Tag, das ist rekordverdächtig. Ob da doch was mit der Hardware nicht stimmt? Ich steig einfach nicht mehr dahinter... (Btw. auch in anderen Foren steht man dem Thema eher ratlos gegenüber - und auf der Kernel Mailing List tauchte das Thema auch mal auf - allerdings bei Version 2.4.2)

[theomega]

Hy,
ich wette darauf das es weg ist wenn du mit "noapic" deinen kernel bootest. Hat bei mir reproduzierbar geholfen. Probiers einfach mal aus.

Gruß
TO

[daemotron]

OK, hab jetzt mal in meiner grub.conf noapic an die Kernel-Zeile drangehängt und neu gebootet - damit sollte es ja eigentlich getan sein. Kennst Du zufällig einen Weg, im laufenden System herauszufinden, mit welchen Argumenten der Kernel tatsächlich gebootet wurde? In /proc bin ich irgendwie nicht fündig geworden...

Hab jetzt mal zum Spaß einen Mirror-rsync angestoßen - dabei hat er sich bisher fast immer in die Hose gemacht. 630 MB hab RX ich jedenfalls schon... mal sehen, wie lange er diesmal durchhält :twisted: Wenn's das denn gewesen sein sollte, geb ich Dir einen virtuellen Kaffee aus (ein echter wäre bis Karlsruhe eh kalt geworden).

[theomega]

Nein, das mit den kernelparametern ist eine gute frage.
Was geht um den apic festzustellen ist ein einfaches "dmesg | grep apic". Wenn er aktiviert ist dann gibt es beim booten eine meldung:

Code: Select all

ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
IOAPIC[0]: apic_id 1, version 32, address 0xfec00000, GSI 0-23
..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1

ansonsten nicht. Aber auch nicht ganz zuverlässig, den irgendwann ist der dmesg-buffer auch voll.

Lass mich wissen wenn es wirklich daran lagt, dann sollte man evtl mal auf Hxxxx zugehen und denen sagen damit sie das ihren Kunden sagen können wenn es nicht geht. Der Support war nämlich leider sehr ratlos!

[elch_mg]

gibts bei euch kein

Code: Select all

 cat /proc/cmdline 

?

[theomega]

ah, danke für den hinweis, kannte ich nicht!

[elch_mg]

Ich hab aus Langeweile mal einen Abend lang /proc durchwühlt.. ;)

[daemotron]

Hehe, danke elch, hab noch einen zweiten Weg gefunden:

Code: Select all

dmesg | grep "Kernel command line"

Allerdings zielte meine Frage nicht ganz darauf ab - was in der Command Line für den Kernel steht, wusste ich ja (hab ich ja selbst reingeschrieben). Wollte eigentlich eher wissen, ob man irgendwo herausfinden kann, was der Kernel mit den übergebenen Parametern schließlich angestellt hat... denn letztendlich könnte da ja auch irrelevanter Mist drin stehen. In /proc habe ich jedenfalls nichts relevantes gefunden, aber das könnte auch daran liegen, dass noapic in der Kernel Command Line tatsächlich den gewünschten Erfolg hatte

@TO: jetzt heißt's leider warten, das letzte Mal lief der Server über 10 Tage ohne Selbstmord durch, danach ist er mir gestern dreimal hintereinander durchgeknallt. Mal sehen, wenn jetzt die nächsten 2-3 Wochen Ruhe ist, kann ich den Spaß wohl als gelöst betrachten :lol:

[Anonymous]

Hallo,

ich hatte diesen Fehler (NETDEV WATCHDOG: eth0: transmit timed out) auch seit gestern - er trat nach dem Upgrade eines Switches auf (100Mbit auf 1Gbit). Scheint somit bei mir mit dem e1000 Treiber zu tun zu haben, der vorher nicht verwendet wurde.

Bin nun auf folgenden Artikel gestossen - dieser beschreibt, dass manche Netzwerkkarten mit dem 82573 Intel Chipsatz eine fehlerhafte Powermanagement-Funktion auf dem EEPROM enabled haben:
http://e1000.sourceforge.net/wiki/index ... g_messages

Vielleicht hilft das dem einen oder anderen weiter, schliesslich ist der Rootforum-Artikel bei Google weit oben :-)

[sticki]

Hi,
ist das Problem reproduzierbar durch den noapic-Parameter verschwunden?

Viele Grüße,
Marc

[daemotron]

Bei mir ja. Der Server läuft seitdem klag- und problemlos; die einzigen Neustarts sind Kernel-Update-bedingt. Ob das als repräsentativ gelten darf, kann ich allerdings nicht sagen...

[anubizz]

Auch wenn dieser Thread schon etwas älter ist, interessiert es vielleicht noch den einen oder anderen.

Ich hatte vor ca. 1 Stunde ebenfalls das Problem, dass mein Server nicht mehr erreichbar war. Es kam dauerhaft zu Timeouts.

Code: Select all

Mar 29 17:45:23 Debian-50-lenny-32-minimal kernel: [  196.706240] r8169: eth0: link up
Mar 29 17:46:05 Debian-50-lenny-32-minimal kernel: [  238.702164] NETDEV WATCHDOG: eth0: transmit timed out
Mar 29 17:46:05 Debian-50-lenny-32-minimal kernel: [  238.706220] r8169: eth0: link up
Mar 29 17:48:18 Debian-50-lenny-32-minimal kernel: [  370.998164] NETDEV WATCHDOG: eth0: transmit timed out
Mar 29 17:48:18 Debian-50-lenny-32-minimal kernel: [  371.002226] r8169: eth0: link up
Mar 29 17:49:06 Debian-50-lenny-32-minimal kernel: [  418.998165] NETDEV WATCHDOG: eth0: transmit timed out
Mar 29 17:49:06 Debian-50-lenny-32-minimal kernel: [  419.002235] r8169: eth0: link up
Mar 29 17:49:42 Debian-50-lenny-32-minimal kernel: [  454.998167] NETDEV WATCHDOG: eth0: transmit timed out
Mar 29 17:49:42 Debian-50-lenny-32-minimal kernel: [  455.002226] r8169: eth0: link up
Mar 29 17:54:18 Debian-50-lenny-32-minimal kernel: [  730.998164] NETDEV WATCHDOG: eth0: transmit timed out
Mar 29 17:54:18 Debian-50-lenny-32-minimal kernel: [  731.002221] r8169: eth0: link up
Mar 29 17:57:00 Debian-50-lenny-32-minimal kernel: [  892.998164] NETDEV WATCHDOG: eth0: transmit timed out
Mar 29 17:57:00 Debian-50-lenny-32-minimal kernel: [  893.002226] r8169: eth0: link up
Mar 29 17:57:24 Debian-50-lenny-32-minimal kernel: [  916.998164] NETDEV WATCHDOG: eth0: transmit timed out
Mar 29 17:57:24 Debian-50-lenny-32-minimal kernel: [  917.002220] r8169: eth0: link up
Mar 29 17:57:48 Debian-50-lenny-32-minimal kernel: [  940.998164] NETDEV WATCHDOG: eth0: transmit timed out
Mar 29 17:57:48 Debian-50-lenny-32-minimal kernel: [  941.002226] r8169: eth0: link up
Mar 29 17:58:42 Debian-50-lenny-32-minimal kernel: [  994.998163] NETDEV WATCHDOG: eth0: transmit timed out
Mar 29 17:58:42 Debian-50-lenny-32-minimal kernel: [  995.002225] r8169: eth0: link up
Mar 29 18:04:48 Debian-50-lenny-32-minimal kernel: [ 1360.998163] NETDEV WATCHDOG: eth0: transmit timed out
Mar 29 18:04:48 Debian-50-lenny-32-minimal kernel: [ 1361.002227] r8169: eth0: link up
Mar 29 18:06:12 Debian-50-lenny-32-minimal kernel: [ 1444.998164] NETDEV WATCHDOG: eth0: transmit timed out
Mar 29 18:06:12 Debian-50-lenny-32-minimal kernel: [ 1445.002226] r8169: eth0: link up
Mar 29 18:07:30 Debian-50-lenny-32-minimal kernel: [ 1522.998163] NETDEV WATCHDOG: eth0: transmit timed out
Mar 29 18:07:30 Debian-50-lenny-32-minimal kernel: [ 1523.002225] r8169: eth0: link up
Mar 29 18:08:18 Debian-50-lenny-32-minimal kernel: [ 1570.998165] NETDEV WATCHDOG: eth0: transmit timed out
Mar 29 18:08:18 Debian-50-lenny-32-minimal kernel: [ 1571.002227] r8169: eth0: link up
Mar 29 18:09:24 Debian-50-lenny-32-minimal kernel: [ 1636.998164] NETDEV WATCHDOG: eth0: transmit timed out
Mar 29 18:09:24 Debian-50-lenny-32-minimal kernel: [ 1637.002221] r8169: eth0: link up
Mar 29 18:09:42 Debian-50-lenny-32-minimal kernel: [ 1654.998167] NETDEV WATCHDOG: eth0: transmit timed out
Mar 29 18:09:42 Debian-50-lenny-32-minimal kernel: [ 1655.002220] r8169: eth0: link up
Mar 29 18:09:54 Debian-50-lenny-32-minimal kernel: [ 1666.998164] NETDEV WATCHDOG: eth0: transmit timed out
Mar 29 18:09:54 Debian-50-lenny-32-minimal kernel: [ 1667.002220] r8169: eth0: link up
Mar 29 18:10:54 Debian-50-lenny-32-minimal kernel: [ 1726.998167] NETDEV WATCHDOG: eth0: transmit timed out
Mar 29 18:10:54 Debian-50-lenny-32-minimal kernel: [ 1727.002221] r8169: eth0: link up
Mar 29 18:12:18 Debian-50-lenny-32-minimal kernel: [ 1810.998164] NETDEV WATCHDOG: eth0: transmit timed out
Mar 29 18:12:18 Debian-50-lenny-32-minimal kernel: [ 1811.002222] r8169: eth0: link up
Mar 29 18:14:54 Debian-50-lenny-32-minimal kernel: [ 1966.998167] NETDEV WATCHDOG: eth0: transmit timed out
Mar 29 18:14:54 Debian-50-lenny-32-minimal kernel: [ 1967.002223] r8169: eth0: link up
Mar 29 18:15:24 Debian-50-lenny-32-minimal kernel: [ 1996.998163] NETDEV WATCHDOG: eth0: transmit timed out
Mar 29 18:15:24 Debian-50-lenny-32-minimal kernel: [ 1997.002225] r8169: eth0: link up
Mar 29 18:15:42 Debian-50-lenny-32-minimal kernel: [ 2014.998169] NETDEV WATCHDOG: eth0: transmit timed out
Mar 29 18:15:42 Debian-50-lenny-32-minimal kernel: [ 2015.002225] r8169: eth0: link up

Ich konnte das Problem ebenfalls durch ein noapic beheben.
Mein Server steht übrigens auch in Nürnberg und wie man dem Auszug aus dem Log entnehmen kann, habe ich ebenfalls eine rtl8169 verbaut.

Gruß AnubiZz

[Anonymous]

Seltsamerweise konnte ich das Problem durch 'noapic' nicht lösen. Auch hier ist es ein r8169.

[daemotron]

Die Transmit Timeouts kann man ev. durch abschalten von TSO beheben. Noapic hilft vor allem bei den Abstüzen, die (wie ich heute weiß) eher auf das Konto von AMD gehen als auf das der Netzwerkkarte... Wenn Du also nur mit den Timeouts, nicht aber mit Systemabstürzen zu kämpfen hast, dann versuch mal

Code: Select all

ethtool -K eth0 tso off

[lazy]

http://wiki.hetzner.de/index.php/Instal ... 8-Treibers