Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
seit dem upgrade meines Servers auf 12.0 gehen die Netzwerkports (4x Intel Karte) eine Weile nach dem Neustart nicht mehr. Ich habe folgende Fehlermeldung im Logfile:
In FreeBSD 12.0 wurden der legacy em Treiber und der igb Treiber in einen neuen Treiber, der iflib verwendet zusammengeführt. Dabei wurde in guter alter Inteltradition mal wieder nur eine Untermenge der aktuellen Hardware getestet. Noch gibt es eine Version des alten Treibers als Port. Das Paket heisst intel-em-kmod.
ja, das Problem habe/hatte ich auch in einem Supermicro Server. Nach der Installation von intel-em-kmod scheint alles wieder gut zu sein.
Grüße, Norbert
habe die intel-em-kmod als paket installiert und über if_em_updated_load="YES" in /boot/loader.conf geladen. Leider bleibt das Problem bestehen. Ersetzt denn der intel-em-kmod den Standardtreibers und muss das Laden dieses Standardtreibers verhindern?
kldstat gibt mir sowohl if_igb.ko als auch if_em_updated.ko aus.
Kann ich akut nicht beantworten. Um sicher zu gehen, kannst du einen Kernel ohne die Treiber bauen und dann den Eintrag in der loader.conf erstmal rausnehmen.
Interessant wäre dann auch dmesg, wenn du kldload if_em_updated absetzt.
Ich musste auch 2x hingucken. Im ersten Post steht es, aber leicht übersehbar.
1x em, 4x igb
Wenn es bei dir so funktioniert, dann wird ein/das Kernelmodul wohl bevorzugt behandelt. pciconf -lv spuckt ja die Treiberinfo aus, aber man kann nicht zwischen 'im Kernel' und Kernelmodul bzw. 'what's in use?' unterscheiden, oder? Den Fall hatte ich auch noch nicht und ich hab bis auf den Link im vorherigen Post nichts gefunden, was die Thematik behandelt.
Ich hatte zwischenzeitlich den alten Treiber daran gehindert zu laden, in dem ich if_igb.ko in if_igb.ko.blacklist umgenannt habe. Das hat leider nichts geändert. Nach einer Weile war die Netzwerkkarte wieder down.
/var/log/messages gibt mir folgendes aus:
Jul 4 20:35:36 Server kernel: igb0: link state changed to UP
Jul 4 20:35:36 Server kernel: igb0: link state changed to DOWN
Jul 4 20:35:37 Server kernel: igb0: TX(0) desc avail = 1024, pidx = 0
Jul 4 20:36:08 Server syslogd: last message repeated 18 times
Jul 4 20:37:53 Server syslogd: last message repeated 63 times
Jul 4 20:37:53 Server kernel: igb0: link state changed to UP
Jul 4 20:37:53 Server kernel: igb0: link state changed to DOWN
Jul 4 20:37:55 Server kernel: igb0: TX(0) desc avail = 1024, pidx = 0
Ich bereue das upgrade auf 12.0 echt. Was ein Mist! Hat jemand noch eine Idee was ich machen könnte?
Ich hatte zwischenzeitlich den alten Treiber daran gehindert zu laden, in dem ich if_igb.ko in if_igb.ko.blacklist umgenannt habe. Das hat leider nichts geändert. Nach einer Weile war die Netzwerkkarte wieder down.
Ich bereue das upgrade auf 12.0 echt. Was ein Mist! Hat jemand noch eine Idee was ich machen könnte?
das ist schade - ich habe zu Hause und 2 "Storage" Server auf meiner Arbeit unter 12.0 laufen - bis auf dieses dumme problem ohne Zwischenfälle. Ich kann dich gut verstehen - habe deswegen am "Vatertag" um 6:30 auf der Arbeit gesessen und den Server wieder neu gestartet, der danach wieder Probleme machte und nachher erstmal eine Rundmail geschrieben, dass er vorrübergehen nicht genutzt werden könne... Wenn mir was sinnvolles einfallen sollte, lass ich es wissen...
"Indeed, running "ifconfig igb3 -tso" did fix the issue. It didn't seem to
the first time, but I may have been too quick to judge. After re-enabling
TSO and disabling it a second time, the problem stopped, and the interface
immediately came up. "
@holgerw hat das "ifconfig -tso" auch erwähnt, allerdings auf em0...
ich habe mal per sysctl net.inet.tcp.tso=0 tso ausgeschaltet und auch noch die entsprechenden Einträge in /etc/sysctl aufgenommen. Leider hat das nichts geändert. Das logfile enthält die gleichen Einträge, und das Netzwerk ist down. Ich werde mir jetzt vorübergehend eine neue Netzwerkkarte mit einem anderen Chip besorgen. Leider läuft meine APU mit Intel-NICs unter 12.0 auch nicht wirklich rund.
Eine Erkenntnis bleibt (erneut). Bei FreeBSD erst auf das nächste Hauptrelease upgraden, wenn es ein zweites Release gibt, also erst ab 12.1. Das wird wohl nicht ausreichend getestet....
Meine APU werde ich jetzt wohl erst mal neu aufsetzen und dort ein 11.X verwenden.
Falls noch jemand etwas einfällt, bin ich ich dankbar, vielleicht gibt es ja doch noch eine Lösung...
Die interfaces sind Bestandteile von bridge0, über die ich weitere Geräte (u.a. einen Drucker) ans Netzwerk angebunden habe.
Leider hat das Ganze nicht den gewünschten Erfolg.
Wenn ich den Drucker anlasse, der an einem der Netzwerkports hängt, scheint der Netzwerkport auch oben zu bleiben. Schalte ich den aber aus und nach 24 Std. wieder ein, kann er nicht mehr angesteuert werden, bis ich den Server, an dessen Netzwerkkarte der Drucker hängt, neugestartet wurde. Vermutlich braucht es ein Mindestmaß an Netzwerkverkehr auf dem Port, damit dieser nicht down ist.
Ich werden jetzt schauen, wie ich auf 11 zurückgehen kann. Was ein Mist!
Ich habe mir eine Quad 82580 Gigabit Network Connection gegönnt, diese nutzt ebenfalls den igb.
Allerdings nutze ich die Karte mit bhyve und passthrough.
Habe nun ähnliche Probleme, bisher fiel es nur unter Last auf (zfs send über igb0). In der vm sehe ich dann, dass igb0 down geht, direkt danach wieder up. Sobald das eintritt, ist die komplette Verbindung weg, sogar ping bleibt tot. Nur ein Neustart der vm hilft.
Hatte zuerst Überhitzung vermutet, daher heute mal einen Lüfter montiert, der direkt auf die Rippen bläst. Danach die FW von 1.3.irgendwas auf 1.5.88 geflasht.
Das powersaving-feature rennt wohl nicht so ideal, wie es sollte. Gelesen habe ich, dass es beim Umschalten der Modi zu den Hängern kommen kann. Auswirkungen vom Zusammenwerfen der Treiber?
Habe gerade mal testweise dev.igb.0.eee_control auf 0 gestellt. Dabei ist die Netzwerkverbindung sofort eingefroren. Ich werde mal meine Bios-Settings anschauen, was ich an Powersaving-Einstellungen gesetzt habe. Vielleicht lässt sich ja so das Problem umschiffen....
Angeblich gibt es für mein Board kein Bios-Update (sagt jedenfalls die eingebaute Update-Lösung, die über das Netzwerk anfragt). Werde mal schauen, ob ich dennoch was neueres finde...
Der Wert 1 soll (laut Thomas Krenn-Seite) aus bedeuten, 0 würde es also einschalten......
Das Problem hat sich zwischenzeitlich erledigt. Die Funktion für das automatische Bios-Update hat zwar immer angegeben, dass es kein Update für das Bios gebe. Es gab aber doch eines das ich manuell installieren musste. Seither habe ich keine Probleme mehr.
Desöfteren habe ich das auch erlebt. Manchmal findet man auf den FTPs (auch mal die aus .tw oder .cn checken) der Hersteller eher was, als direkt von der Homepage.
Insgesamt aber sehr interessant. Hast du ein changelog zu dem update, wo man mal genauer nachschauen kann oder einfach die Modellbezeichnung deines Boards?
