Wir ertrinken in Information, aber hungern nach Wissen [John Naisbitt]

Site menu:


Letzte Kommentare

Links:

Counter

blogoscoop

Bloggerei

Blogverzeichnis - Blog Verzeichnis bloggerei.de

Archiv

Tag Cloud

Haste forcedeth, haste Ärger

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.

Verwandte Artikel

1. Kommentar von prodigy7 | Datum: 4.Juli 2008

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…

2. Pingback von from hades » forcedeth | Datum: 4.Juli 2008

[...] 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 ;-) [...]

3. Kommentar von Bernd Wachter | Datum: 4.Juli 2008

Das Ding heisst nicht umsonst `force death’, die Entwickler haben sich nur anscheinend mal vertippt und das nicht korrigiert.

4. Kommentar von Patrick | Datum: 6.Juli 2008

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.

5. Kommentar von Stefan | Datum: 6.Juli 2008

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