Haste forcedeth, haste Ärger
3. Juli 2008 | 
Autor: Es gibt Netzwerk-Hardware unter Linux von der sollte man die Finger lassen. Karten mit RTL- oder VIA-Rhine Chipsätzen können funktionieren – müssen es aber nicht. Genauso sieht es mit Nvidia-Chipsätzen aus, dessen forcedeth-Treiber eine richtige Schneise durch Linux-Foren gezogen hat.
Intressanterweise gibt es Server-Hersteller, wie z.B. Sun, die so etwas verbauen. Deren ersten Opteron-Server hatten noch vier e1000-Karten für die es imho die besten Treiber gibt die man unter Linux haben kann. In der folgenden M2-Serie gab es dann zwei Nvidia und zwei e1000 Karten, eine Entscheidung für die Sun (zu Recht) ordentlich Prügel eingesteckt hat. Man gab sich geläutert und versprach zukünftig das Mixen zu lassen. Wer nun denkt es gäbe wieder vier e1000-Karten liegt falsch, denn z.B. die X4240 hat vier Nvidia-Karten, womit der Spass selbst unter dem supporteten RHEL losgehen kann.
Sun wurde wohl schon selbst davon getroffen, denn in den Server Product Notes gibt es den schönen Eintrag Heavy, Sustained Disk and Network I/O Might Cause Server to Hang or Display “Soft Lockup” Message, der aber nur eine mögliche Fehlermeldung beschreibt. Viel Bekannter dürfte die hier sein:
too many iterations (6) in nv_nic_irq
Damit muss der Spass aber noch nicht Zuende sein, denn an kann nämlich auch noch
kernel: NETDEV WATCHDOG: eth0: transmit timed out kernel: eth0: Got tx_timeout. irq: 00000037 kernel: eth0: Ring at 1213a2000 kernel: eth0: Dumping tx registers
sehen. Danach ist die Netzwerkkarte tot. Tja und nun kann man Anfangen zu raten. Das Internet ist voll von Lösungsansätzen, die aber alle nicht wirklich passen wollen. Ich hab fürs Erste das tcp segmentation offload des Treibers mit
ethtool -K eth0 tso off
abgeschaltet. Seitdem ist Ruhe – fragt sich nur wie lange und ich kann in der Zwischenzeit mal darüber nachdenken, warum Sun die Nvidia-Netzkarten für eine gute Lösung hält.
Update: Nö, hilft nix. Notfalls kann man im laufenden Betrieb rmmod forcedeth; modprobe forcedeth machen, dann spart man sich einen Neustart.
Schlagworte:
Die Treiber machen wirklich überall Probleme… das “netteste” was ich erlebt habe ist, dass nach dem aufwachen aus dem Suspend to RAM die MAC-Adresse einen beliebig zufälligen Wert hatte.
Da wirds dann Zeit für ausgewachsene UDEV Regeln, damit man normal weiter arbeiten kann…
[...] Wenn ich Joerns ach und weh dort betrachte und meine eigenen Erfahrungen hinzunehme in Linux, FreeBSD und zum Teil auch mal in Windows, dann könnte man glatt auf unzureichende Hardware schließen. nVidia sucks? Vielleicht, jedenfalls bestücke ich bei nVidia Nics die Geräte stante pede mit anderen jedweder Natur und sie sind gefügiger ;-) [...]
Das Ding heisst nicht umsonst `force death’, die Entwickler haben sich nur anscheinend mal vertippt und das nicht korrigiert.
Ein Grund die Finger von den Kisten zu lassen. Hoffentlich korrigiert SUN diese Entscheidung bei der nächsten Serie. Ich hoffe auch, dass kein anderer Hersteller auf den Zug aufspringt.
Die Dinger sind wirklich skuril. Ich hatte hier ein altes ASUS-Board welches neben einem 3com ein forcedeth Interface onbard hatte. Leider hatte dieses eine illegale MAC-Adresse. (Ein Bit im Host-Anteil der Adresse signalisiert Multicastbetrieb und darf vom Hersteller nicht verwendet werden(?).) Der Linux-Kern meckerte das beim Booten an und teilte eine zufällige Adresse zu. Leider ist udev in der Regel so konfiguriert das es sich an der Adresse orientiert und dann brav jedes mal eine neue Regel für das (neue) Interface bastelt. Es gibt also so lange Spaß mit dem Ding bis man selbst eine extra Regel erfand und eine feste, gültige Adresse zuteilte.
Das 3com Interface zu benutzen war grundsätzlich die bessere Idee aber leider lief damit kein wake on lan. Aber jetzt ist es kaputt :-)