8.1-RELEASE und igb / em Freezes ...

K

kai_001

Well-Known Member
Hi,

habe einen 3HE Server mit SuperMicro X8DT3 Board. Erst gab es massive Probs mit den Onboard Karten ( igb ), kein Login mehr möglich ... nur Reboot per IPMI half. Jetzt habe ich eine Dual Port Intel Karte ( GB, Server Version ). Auch hier stoppt das Netzwerk nicht reproduzierbar, der Login geht zwar noch ( lokal ), aber keine Reaktion der Interfaces ( raus, rein ). Ich habe keine Idee mehr. MBufs waren bei em Karte kurz vor voll ( habe auf 120000 gestellt ). Erhöhen brachte kein wiederbeleben. Nur reboot hilft / half.

Andere Netzwerkkarte? Welche? 3Com, Allied Telesis? Langsam verzweifele ich ein bissel.

Der Server stellt ein raidz2 per NFS zur Verfügung. Nur zur Info.

Danke
Kai
 
Mal ins Blaue geraten, hast du den Server auch mal mit nur einer CPU/Core laufen lassen, um SMP Probleme auszuschließen?
 
Das ist leider bekannt. Sowohl igb(4) als auch em(4) (basieren beide dem gleichen Code) ist in 8.1 leider defekt, weil die Intel-Truppe mal wieder erst recht spät neue Versionen ins 8-STABLE eingefügt hatte. Ich ziehe gerade die Konsequenzen und werde in Zukunft auf Broadcom setzen, ich bin die dauernden Treiberprobleme mit den Intel-NICs nämlich Leid. In 7.2 und 8.0 hatten die auch schon nette Bugs, die auch daher kamen, da man mal wieder erst schnell noch eine neue Version durchdrücken musste und mit den Fehlerkorrekturen zu spät war... So, genug aufgeregt, dir kann geholfen werden: Einfach den angehängten Patch rein (ja, das nervt) oder auf 8-STABLE gehen. Eventuell wird es eine Erratta dazu geben, dann kommt's mit freebsd-update.
 

Anhänge

  • e1000-releng8.txt
    68,3 KB · Aufrufe: 399
Hallo Yamagi,

endlich gute Neuigkeiten! Stable geht nicht, twa kaputt ( Tom von LSI konnte meinen Bug reproduzieren und arbeitet dran ). Dein Patchfile hat beim Release Fehler geworfen. Hab mir jetzt e1000 ausm Stable gezogen und baue grade Kernel neu. Ich hoffe und berichte. Danke schonmal für den Tipp.

Grüße
Kai
 
Ja, der aus -STABLE sollte auch funktionieren. Man müsste sogar ohne größere Probleme den Code von Intel selbst beziehen können. Der findet sich irgendwo in den tiefen ihrer Homepage und ist eventuell noch neuer.
 
Yamagi schrieb:
Das ist leider bekannt. Sowohl igb(4) als auch em(4) (basieren beide dem gleichen Code) ist in 8.1 leider defekt,
Zum Vergrößern anklicken....

Hmm, wenn ich die Mailinglisten verfolge - kann es sein, dass der ganze em rework bei FreeBSD nicht gutgetan hat ?

http://www.mail-archive.com/freebsd-stable@freebsd.org/msg110244.html
Jack, did you break em(4) (or lem in this case) again? :-)
Zum Vergrößern anklicken....

Wo ist da der Schuldige zu suchen? Wirklich nur Intel?

Muss leider berichten, dass in unserer Testfarm einige Rechner mit Intel PRO 1000 GT/PT mit FreeBSD 8.x Komplett-Ausfälle zeigen, ähnlich wie berichtet. Bei den Kisten hilft nur noch der Reset-Knopf. Reproduzierbar unter Netzwerk-Last, hab bis jetzt vehement andere Ursachen gesucht, aber nun werd ich skeptisch...

Die meisten unserer Server haben Intel-Karten an Bord, weil die immer einfach ne Bank an Zuverlässigkeit waren - ist da eine große Trendwende am Horizont ?

edit: Wenn die Intel-Karten ein Major-Problem darstellen - auf was sollen wir dann längerfristig umstellen ? Broadcom dann ?
 
Zuletzt bearbeitet:
Guten Morgen :)
Ja, der Intel-Treiber zickt praktisch herum, seitdem er in em(4) und igb(4) gespalten wurde. Das war seinerzeit zu 7.2 der Fall, falls ich es nun richtig im Kopf habe. Ich finde es zwar schön, dass Intel FreeBSD unterstützt, aber ich würde mir wünschen, wenn man mal wieder ein wenig mehr Wert auf Qualität bei diesem Treiber legen würde. Es geht dabei nicht einmal so wirklich um den Kern, der ist unter Windows und Linux gleich. Stattdessen um den plattformabhängigen Teil, der in schöner Regelmäßigkeit zerdeppert wird.

An dieser Stelle kommt auch Jack Vogel ins Spiel. FreeBSD vergibt Commit-Bits nur an Individuen, nicht an Organisationen. Das soll sicherstellen, dass es immer einen Ansprechpartner gibt, der verantwortlich ist und das derjenige auch das FreeBSD Mentor-Programm durchlaufen hat. Jack Vogel ist Intel-Mitarbeiter und fügt als FreeBSD-Committer Intels Änderungen in FreeBSD ein. Würde rein hypothetisch Jack Intel nun verlassen, müsste sein Nachfolger das Mentor-Programm wie jeder andere Committer auch durchlaufen und so nach und nach in die FreeBSD-Gemeinschaft eingeführt werden. Es gibt auch andere Firmen, deren Vertreter Committer sind, zum Beispiel Isilon Systems oder Netapp.

Bei dem Intel-Treiber ist es seit längerem immer das gleiche Spiel, was auch der sarkastische Kommentar "Jack, did you break em(4) (or lem in this case) again? :-)" unterstreicht. FreeBSD will ein Release machen, daher gibt es einen Code-Freeze. Zum Beispiel am 15. Mai. Das wird angekündigt und nun will Intel noch ganz schnell eine neue Version rein haben. Die wird in -CURRENT committet, nun würde man je nach Größe der Änderung zwischen 3 und 90 Tagen warten, bei neuen Treiberversionen sind es meist 30. Da nun aber der Code-Freeze vor der Tür steht, fließt es schon nach 3 Tagen zurück ins -STABLE. Viel zu wenig, um größere Fehler erkennen zu können. Der Code-Freeze kommt, die Fehler werden nun gefunden. Es gibt Patches, nicht selten sogar von Nicht-Intel-Committern. Diese Patches fließen schnell zurück in -STABLE, da wir im Codefreeze sind, muss releng@ (leitet den Release-Prozess) für jeden Patch eine Freigabe erteilen. Irgendwann kommt aber der Punkt - meist spätestens mit RC1 - wo nur noch sehr kritische Fehler behoben werden und alle anderen drin bleiben, da man sonst nie fertig werden würde. Und das ist hier passiert. Der rettende Patch kam zu spät und wurde nicht mehr akzeptiert, mit dem Hinweis, dass man nach dem Release und einer längeren Testphase eine Errata schreiben könnte und damit per freebsd-update z.B. im Zuge von FreeBSD 8.1-p1 patchen. All diesen Ärger gebe es nicht, wenn man sich an die ungeschriebene Regel halten würde, das neue Treiberversionen mindestens 30 Tage sacken, bevor sie in -STABLE eingehen. Was problemlos möglich wäre, wenn diese neuen Versionen nicht immer auf den letzten Drücker in ein RELEASE gepresst werden müssten.

Grützig ist hier keinesfalls die Hardware. Da baut Intel noch immer das beste, was man für Geld kaufen kann. Das Problem ist einzig und allein der Stil, in welchem der Treiber in FreeBSD zurückfließt. Nur wenn das nicht besser wird, wird Intel wahrscheinlich ersetzt werden. Broadcom erscheint mir ganz gut, läuft als Onboard-Karte in meinen Opteron-Servern zumindest einwandfrei. Alternativ kann man natürlich versuchen sich eine neuere Treiberversion direkt von http://downloadcenter.intel.com/default.aspx zu ziehen und zu installieren.
 
Guten Morgen

sehr ausführliche Darstellung des Problems, klasse.

Was ist mit Allied Telesys oder 3Com oder z.b. Cisco Karten? Hat jemand Erfahrungen mit diesen Herstellern? Habe mein Vertrauen in Intel durch viele schlaflose Nächte echt ein bissel verloren ...

Grüße
Kai
 
3Com gibt es nicht mehr. Sie bauten schon länger keine eigenen NICs mehr, was es noch gab waren zugekaufte Karten von Drittherstellern. Inzwischen wurde die Firma aber eh von HP übernommen und eingestampft. Bei HP habe ich ehrlich gesagt keinen Überblick, sollte man sich aber vielleicht mal näher anschauen...
 
Morsche an alle,

Kai, läuft das Board abgesehen von dem NIC-Problem ordentlich? Ich wollte mir demnächst wohl auch eine Supermicro-Maschine speziell für ZFS wo direkt an den Onboard-SAS Controller gegangen wird zulegen und da wäre das Board mit dem LSI 1068E Controller ein Kandidat. (Ansonsten suche ich alternativ eine Opteron-Lösung.)

Thanks in advance.
 
Hi,

der Controller wird ja per mpt gehandelt. Ich habe aber einen 3Ware Controller für die hdd's dazwischen gesteckt ( Single Devices ) und System Hardware RAID1.

Sonst keine Probleme bis auf igb, em ... mpt kann ich dir leider nix zu sagen, da abgeschalten. Die IPMI ist ne sehr schöne Geschichte, keine externen APC's und Terminalserver notwendig ( möchte ich nicht mehr drauf verzichten ).


Grüße
Kai
 
Ui, danke für deine schnelle Antwort.

D.h., du vertraust also doch lieber dem guten 3Ware Controller die Platten an. Gut, im Fall irgend eines Problems mit dem LSI 1068E müsste ich dann auch wieder dazu übergehen.

Stimmt, wegen IPMI wollte ich auch kurz nachfragen. Das hört sich doch alles gut an und das Board ist ganz klar auch ein Kandidat für mich.

Danke.
 
Nochmal zurück zu den NICs, Broadcom wurde als brauchbare Alternative zu Intel genannt. Wie siehts mit Marvell/SysKonnect (msk Treiber) aus? Was taugen die?
 
cosmo schrieb:
Nochmal zurück zu den NICs, Broadcom wurde als brauchbare Alternative zu Intel genannt. Wie siehts mit Marvell/SysKonnect (msk Treiber) aus? Was taugen die?
Zum Vergrößern anklicken....

Wenn ich es noch richtig in Erinnerung habe, sind Marvell eher problematisch in FreeBSD. Mir wurde jedenfalls immer Intel :ugly: und Broadcom empfohlen.
 
HP hat auch (fast) nur intel und Broadcom verbaut.
Was ist mit SunHardware? Da gibt es doch auch Gbit-Nic?

Gruß ré
 
Unsere SUN V240, die bei uns intern ihr Gnadenbrot fristet hat auch Broadcom NICs und unsere X2270 von Ende 2009 haben ebenfalls Broadcom NICs verbaut.

Gruß c.
 
Hi,

was ich gesehen habe, HP verbaut echt die Intel Chips.

Mit den letzten Patches lief das System jetzt aber sauber durch, bis auf die twa Probs :confused:

Grüße
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben