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.
und Broadcom empfohlen.