acpiconf -s 3 -> nach Resume kommt das Netzwerk nicht hoch

Frank

Anfänger
Hallo zusammen,

einer meiner Server zickt nach dem Update auf FreeBSD 12.

Unter 11.2 habe ich den Rechner immer mittels "acpiconf -s 3" schlafen gelegt, um Strom zu sparen.
Wenn ich den Rechner per wakeOnLan geweckt habe, blieb zwar immer der Monitor schwarz, aber das war mir völlig egal, da ich immer per SSH den Rechner administriere.
Nach dem Update auf FreeBSD12 (und auch nach einem CleanInstall) weckt zwar der Rechner auf, aber ich kann mich nicht mehr per SSH einloggen,
da das Netzwerk nicht hoch kommt.
Ich kann mich blind lokal einloggen und den Rechner per reboot neustarten. Er reagiert also. Lokal und blind das Netzwerk (netif und routing) neustarten,
klappt nicht.
Im Bios USB auszustellen hat auch nichts gebracht.

Wie kann ich herausfinden welcher Treiber Probleme macht oder wie kann ich vorgehen, um das Problem einzugrenzen.
Das Handbuch und die man-Page zu acpi konnten mir bisher leider nicht weiterhelfen.

Viele Grüße
Frank
 
Ha ich hab genau das gleiche Problem. Nach acpiconf -s 3 kommt seit dem 12 Update das Netzwerk nicht mehr hoch - zumindest kein Zugang per SSH mehr.
Hatte allerdings noch nicht die Zeit mich näher damit zu beschäftigen.
 
Ich für meinen Teil hab noch garnichts probiert da ich derzeit noch keine Zeit dafür hatte, das Ding läuft erstmal einfach durch. Aber da es mit 11.2 ja problemlos funktionierte denke ich nicht, dass es an meiner HW liegt. Zudem sind die Dell-Teile da meist sehr Standardkonform. Wollte nur beschied geben, dass der OP nicht der einzige mit diesem Problem ist :)
 
Ich nehme mal an, die im Handbuch beschrieben Sachen zwecks Ergründung etwaiger Probleme wurden schon durchprobiert?
https://www.freebsd.org/doc/de/books/handbook/acpi-overview.html#ACPI-comprob
Das habe ich alles probiert.

Die Onboard-Netzwerkkarte ist eine igb0.
Unter 11.2 konnte ich diese nicht aufwecken, so dass ich eine externe em0 eingebaut habe, die immer problemlos funktionierte.

Jetzt unter 12 kann ich auch den Rechner über die igb0 aufwecken.
Allerdings kommt bei beiden Netzwerkkarten das Netzwerk nicht hoch.

Ausgabe ifconfig (die em0 habe ich gerade zum Testen rausgenommen):

igb0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=e527bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,WOL_MAGIC,VLAN_HWFILTER,VLAN_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6>
ether 0c:c4:7a:XX:XX:XX
inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>

lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
options=680003<RXCSUM,TXCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
inet 127.0.0.1 netmask 0xff000000
groups: lo
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>

In /var/log/messages sieht auch alles gut aus.

Wenn ich aber suspend/resume simuliere mit
# sysctl debug.bootverbose=1
# sysctl debug.acpi.suspend_bounce=1
# acpiconf -s 3
dann geht es manchmal gut und manchmal kommt permanent die Ausgabe der Zeile
igb0: TX(2) desc avail = 1024, pidx = 0
Auf einer anderen Konsole kann ich nicht mehr pingen(ping: sendto: No Buffer space available) und
ifconfig zeigt an:
igb0 status: no carrier

/etc/rc.cd/./netif restart bringt das Netzwerkinterface auch nicht hoch.

Ob das ein Interrupt-Problem ist?
In einigen wenigen Fällen klappt das aufwecken. Aber meistens leider nicht :(
 
Oh-ha. Du verteilst aber ne knifflige Aufgabe. :-)
Vielleicht muss man die Hardware selbst irgendwie resetten.
Da muss ich erst mal drüber schlafen :-)
 
Oh-ha. Du verteilst aber ne knifflige Aufgabe. :-)
Vielleicht muss man die Hardware selbst irgendwie resetten.
Da muss ich erst mal drüber schlafen :-)
Danke!
Ich muss auch ein bisschen drüber schlafen.
Nur Strom zu sparen ist mir wirklich wichtig. Ich teste es die Woche mal mit 11 und gucke mal ob irgendwer noch auf das gleiche Problem gestoßen ist.
 
Ich für meinen Teil hab noch garnichts probiert da ich derzeit noch keine Zeit dafür hatte, das Ding läuft erstmal einfach durch. Aber da es mit 11.2 ja problemlos funktionierte denke ich nicht, dass es an meiner HW liegt. Zudem sind die Dell-Teile da meist sehr Standardkonform. Wollte nur beschied geben, dass der OP nicht der einzige mit diesem Problem ist :)
Ich hoffe ein bisschen auf 12.1 :)
 
Hilft es das Modul vor dem Suspend zu entladen und nach de Resume wieder zu laden?
 
Hilft es das Modul vor dem Suspend zu entladen und nach de Resume wieder zu laden?
Ich weiß nicht, welches Modul er wo und wann lädt.
Denn im Generic-Kernel finde ich nicht die Option "device igb". dmesg zeigt mir aber an, dass das Modul igb geladen ist. Es funktioniert ja auch :)
In den diversen loader.conf Dateien finde ich auch nirgends ein igb.
kldstat zeigt auch kein igb-Modul an.
Dann müßte es doch eigentlich im Kernel zu finden sein.
device em finde ich zum Beispiel ja auch im Kernel.

Wenn ich kldunload ig4.ko direkt nach dem reboot eingebe, erscheint "can't find file ig4.ko".
Wenn ich das Modul dann mit kldload ig4.ko lade, kann ich es natürlich auch wieder entladen.

Komisch finde ich auch, dass ich die man-Page zu igb nicht finde auf meinem Rechner. Auf der FreeBSD Website finde ich die man-Page auch für FreeBSD12.

Lange Rede kurzer Sinn. Ich wüßte gerne welches Modul er wann wo lädt. Dann würde ich das beim Starten mal ausstellen und händisch laden und entladen, um zu gucken was so passiert.

Tada....es scheint em zu sein. Ich habe den Chipsatz i210AT von Intel. Und der wird vom em-Treiber unterstützt. Warum dann igb angezeigt , keine Ahnung.
Morgen werde ich mal einen Kernel ohne em bauen und em händisch nachladen und entladen.
 
Zuletzt bearbeitet:
Ich hab heute auch etwas Zeit gefunden:

Bei mir werkelt ne Intel Pro mit dem EM Treiber. Wie gesagt mit 11.X hat alles immer Problemlos geklappt.

Leider wacht anch einem Resume auch die Grafik nicht ordentlich auf - der Monitor bleibt schwarz. Ob das mit 11.X geklappt hat weiß ich allerdings nicht, da ich normal an der Maschine keinen Monitor hängen hab. Im Syslog sieht man, vor dem Resume wird das em0 korrekt auf DOWN gesetzt, beim Resume wieder auf UP. Die Netzwerkeinstellungen passen auch, auch ein netif restart nach dem Resume hilft nichts (hab das alles per atrun machen lassen - wie gesagt kein Monitor). Auch die Firewall (pf) hab ich schon ausgeschlossen. Ein ab und wieder Anstecken des Netzwerkkabels wird nach dem Resume ebenfalls ordentlich im syslog verzeichnet.

Befürchte ich muss wirklich mit Debug-Optionen bauen, dafür fehlt mir leider grad wirklich die Zeit :/ Vielleicht hat ja noch jemand ne Idee. Sieht aber sehr danach aus, als wäre es genau das gleiche Problem wie das des OP.


ifconfig:
Code:
em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=81249b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,LRO,WOL_MAGIC,VLAN_HWFILTER>
        ether 00:21:9b:XX:XX:XX
        inet 192.168.XXX.XXX netmask 0xffffff00 broadcast 192.168.XXX.255
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
 
Wenn ich kldunload ig4.ko direkt nach dem reboot eingebe, erscheint "can't find file ig4.ko".
Wenn ich das Modul dann mit kldload ig4.ko lade, kann ich es natürlich auch wieder entladen.

ig4 ist nicht was du suchst, wie kommst du auf dieses Modul? Es ist für einen i2c controller: https://www.freebsd.org/cgi/man.cgi?query=ig4&sektion=4&manpath=freebsd-release-ports

Wenn igb nicht in der Kernelkonfiguration gelistet ist, wird es als Modul gebaut.
Was passiert, wenn du
Code:
kldload igb
eingibst?

Rob
 
if_igb.ko ist beginnend ab 12.0 nur noch ein Dummy-Modul, genauer ein Hartlink auf if_em.ko, um vorhandene Konfigurationen nicht zu brechen:
Code:
302465 -r-xr-xr-x  2 root  wheel   461K 21 Dez. 14:07 if_em.ko
302465 -r-xr-xr-x  2 root  wheel   461K 21 Dez. 14:07 if_igb.ko

Entsprechend findet sich in der Kernel-Config auch nur noch device em als einziger kombinierter Treiber für alle Intel 1GBit/s Karten. Die Intel PRO/1000 Familie halt. :)
 
if_igb.ko ist beginnend ab 12.0 nur noch ein Dummy-Modul, genauer ein Hartlink auf if_em.ko, um vorhandene Konfigurationen nicht zu brechen:
Code:
302465 -r-xr-xr-x  2 root  wheel   461K 21 Dez. 14:07 if_em.ko
302465 -r-xr-xr-x  2 root  wheel   461K 21 Dez. 14:07 if_igb.ko
Danke.
Woran hätte ich das sehen können?
 
Ich habe mir jetzt eine Netzwerkkarte für den Treiber if_re.ko besorgt und WakeOnLan funktioniert wie unter 11.2.
Der Bildschirm bleibt nach wie vor schwarz, dass ist mir aber egal.

Zudem will ich mir eine kleine Schaltung bauen (Bauteile sind gerade angekommen: Optokoppler usw.) die einen Raspberry Pi erweitert, um den Power-Switch des Rechners remote betätigen zu können.
Ich werde hier berichten.

Danke für die Hilfe.
 
Hatte heute endlich Zeit um mir das Problem etwas anzusehen. Hier gibts nen Bugeintrag, der unser Problem beschreibt: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231828

Verlinkt ist auch ein weiterer Bugreport mit einem Patch. Ich hab den mal getestet und funktioniert bisher einwandfrei über mehrere Suspend/Resume tests.

Hier der Patch:
Code:
Index: iflib.c
===================================================================
--- iflib.c(revision 341824)
+++ iflib.c(working copy)
@@ -4894,7 +4894,7 @@
 
 CTX_LOCK(ctx);
 IFDI_RESUME(ctx);
-iflib_init_locked(ctx);
+iflib_if_init_locked(ctx);
 CTX_UNLOCK(ctx);
 for (int i = 0; i < NTXQSETS(ctx); i++, txq++)
 iflib_txq_check_drain(txq, IFLIB_RESTART_BUDGET);
 
Es ist geplant in naher Zukunft eine Errata zu iflib für 12.0 rauszugeben. Aber keine Ahnung, ob das hier darin enthalten sein wird.
 
Zurück
Oben