NETDEV WATCHDOG: eth0: transmit timed out

FreeBSD, Gentoo, openSUSE, CentOS, Ubuntu, Debian
User avatar
daemotron
Administrator
Administrator
Posts: 2800
Joined: 2004-01-21 17:44

NETDEV WATCHDOG: eth0: transmit timed out

Post by daemotron » 2007-04-06 23:49

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
Userprojekt
Userprojekt
Posts: 704
Joined: 2003-01-27 14:36

Re: NETDEV WATCHDOG: eth0: transmit timed out

Post by theomega » 2007-04-11 00:29

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
Posts: 68
Joined: 2006-01-12 17:01

Re: NETDEV WATCHDOG: eth0: transmit timed out

Post by ephigenie » 2007-04-11 01:48

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

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

theomega
Userprojekt
Userprojekt
Posts: 704
Joined: 2003-01-27 14:36

Re: NETDEV WATCHDOG: eth0: transmit timed out

Post by theomega » 2007-04-11 11:36

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

User avatar
daemotron
Administrator
Administrator
Posts: 2800
Joined: 2004-01-21 17:44

Re: NETDEV WATCHDOG: eth0: transmit timed out

Post by daemotron » 2007-04-13 12:45

theomega wrote: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
Userprojekt
Userprojekt
Posts: 704
Joined: 2003-01-27 14:36

Re: NETDEV WATCHDOG: eth0: transmit timed out

Post by theomega » 2007-04-13 13:55

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

User avatar
daemotron
Administrator
Administrator
Posts: 2800
Joined: 2004-01-21 17:44

Re: NETDEV WATCHDOG: eth0: transmit timed out

Post by daemotron » 2007-04-13 19:55

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

Re: NETDEV WATCHDOG: eth0: transmit timed out

Post by Anonymous » 2007-04-17 09:56

jfreund wrote:
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

User avatar
daemotron
Administrator
Administrator
Posts: 2800
Joined: 2004-01-21 17:44

Re: NETDEV WATCHDOG: eth0: transmit timed out

Post by daemotron » 2007-04-17 14:00

mihde wrote: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:
mihde wrote: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.
mihde wrote: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.

User avatar
daemotron
Administrator
Administrator
Posts: 2800
Joined: 2004-01-21 17:44

Re: NETDEV WATCHDOG: eth0: transmit timed out

Post by daemotron » 2007-05-03 16:09

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
Userprojekt
Userprojekt
Posts: 704
Joined: 2003-01-27 14:36

Re: NETDEV WATCHDOG: eth0: transmit timed out

Post by theomega » 2007-05-03 16:35

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

User avatar
daemotron
Administrator
Administrator
Posts: 2800
Joined: 2004-01-21 17:44

Re: NETDEV WATCHDOG: eth0: transmit timed out

Post by daemotron » 2007-05-03 17:51

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
Userprojekt
Userprojekt
Posts: 704
Joined: 2003-01-27 14:36

Re: NETDEV WATCHDOG: eth0: transmit timed out

Post by theomega » 2007-05-03 19:01

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
Posts: 302
Joined: 2006-01-23 19:14
Location: 41063

Re: NETDEV WATCHDOG: eth0: transmit timed out

Post by elch_mg » 2007-05-03 20:44

gibts bei euch kein

Code: Select all

 cat /proc/cmdline 
?

theomega
Userprojekt
Userprojekt
Posts: 704
Joined: 2003-01-27 14:36

Re: NETDEV WATCHDOG: eth0: transmit timed out

Post by theomega » 2007-05-03 21:01

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

elch_mg
Posts: 302
Joined: 2006-01-23 19:14
Location: 41063

Re: NETDEV WATCHDOG: eth0: transmit timed out

Post by elch_mg » 2007-05-03 21:06

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

User avatar
daemotron
Administrator
Administrator
Posts: 2800
Joined: 2004-01-21 17:44

Re: NETDEV WATCHDOG: eth0: transmit timed out

Post by daemotron » 2007-05-04 08:15

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 :wink:

@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

Re: NETDEV WATCHDOG: eth0: transmit timed out

Post by Anonymous » 2007-06-08 09:19

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
Posts: 11
Joined: 2003-03-13 00:11

Re: NETDEV WATCHDOG: eth0: transmit timed out

Post by sticki » 2008-01-07 09:30

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

Viele Grüße,
Marc

User avatar
daemotron
Administrator
Administrator
Posts: 2800
Joined: 2004-01-21 17:44

Re: NETDEV WATCHDOG: eth0: transmit timed out

Post by daemotron » 2008-01-09 00:00

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
Posts: 3
Joined: 2006-12-18 19:51

Re: NETDEV WATCHDOG: eth0: transmit timed out

Post by anubizz » 2009-03-29 18:35

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

Re: NETDEV WATCHDOG: eth0: transmit timed out

Post by Anonymous » 2009-04-30 19:04

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

User avatar
daemotron
Administrator
Administrator
Posts: 2800
Joined: 2004-01-21 17:44

Re: NETDEV WATCHDOG: eth0: transmit timed out

Post by daemotron » 2009-04-30 20:33

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
“Some humans would do anything to see if it was possible to do it. If you put a large switch in some cave somewhere, with a sign on it saying 'End-of-the-World Switch. PLEASE DO NOT TOUCH', the paint wouldn't even have time to dry.” — Terry Pratchett, Thief of Time

lazy
Posts: 1
Joined: 2009-10-14 11:12

Re: NETDEV WATCHDOG: eth0: transmit timed out

Post by lazy » 2009-10-14 11:13