Wake-On-Lan-Option wird ausgeschaltet bei Suspend
Hallo, ich habe ein Fehlverhalten in der SuSE 9.3 Personal Edition festgestellt und bräuchte nun einen Ansprechpartner mit Know-How. Es handelt sich dabei um die Problematik, daß Wake-On-LAN (WOL) nach einem Suspend-to-Disk nicht funktioniert. Ich vermute einen Fehler in den Skripten, die bei einem Suspend/Resume abgearbeitet werden. Im Detail: Ich betreibe eine 3COM 3C905-TXM an einem Gigabyte BX2000. Sowohl die Karte als auch das Mainboard (nicht PCI 2.2) verfügen über einen WOL-Stecker, die ich miteinander verbunden habe. Das Treibermodul (3c59x) lade ich mit dem Parameter "enable_wol=1", um Wake-On-Lan einzuschalten. Danach schicke ich den Rechner mittels "echo disk > /sys/power/state" schlafen. Die Karte wird weiter mit Strom versorgt, die Link-LED leuchtet. Soweit so gut. Das Problem: Der Rechner wacht nach Empfang eines Magic Packets (generiert mittels dem Tool WOL) nicht auf. Die LED am NIC blinkt nur kurz und nichts passiert. Was ich soweit herausgefunden habe: Kurz bevor sich der Rechner schlafen legt, wechselt der Bildschirm auf eine andere virtuelle Konsole (ich weiß leider nicht, welche und wie ich ohne Suspend dorthin gelange). Auf dieser sind Ausgaben wie "Stopping Tasks" oder "PM: attempting to suspend to disk" zu sehen. Man sieht in diesem Screen nun, daß beim Suspend zunächst vortex_down() aufgerufen wird (ich habe im Kernelmodul 3c59x mehrere Debug-Ausgaben eingebaut). In dieser Funktion wird das WOL eingeschaltet (Funktion acpi_set_WOL() ). Gut. Aber nur kurze Zeit später, kurz bevor der Rechner dann endgültig ausgeht, wird erneut vortex_up() ausgeführt, was dazu führt, daß das entsprechende Register in der Karte wieder gelöscht wird und anschließend WOL nicht funktioniert. Ich habe daraufhin im Modul 3c59x einen Workaround eingehackt. Ich setze in der Funktion vortex_down() eine globale Variable 'shutdown_in_progress' auf 1. In vortex_up() wird nun als erstes überprüft, ob diese Variable 1 ist. Falls ja, wird die Variable zurückgesetzt und die Funktion sofort verlassen. Falls nein, wird die Funktion ganz normal ausgeführt. Und siehe da: Mit diesem Workaround funktioniert es! Die Karte erkennt das Magic Packet korrekt und der Rechner wacht auf. Sowohl die Hardware als auch die Software sind also soweit in Ordnung. Das Problem ist, daß kurz vor dem eigentlichen Suspend nochmals vortex_up() aufgerufen wird und damit die WOL-Settings der Karte verloren gehen. vortex_up() wird bei einem device_open() aufgerufen. Irgendjemand öffnet also nochmals die Netzwerkkarte. Ich weiß nur nicht, wer. Ich frage mich nun, welche Skripte werden denn vor einem Suspend ausgeführt? Wo finde ich bei einer SuSE 9.3 die entsprechenden Dateien? Der eingebaute Workaround funktioniert zwar beim Suspend, beim Resume jedoch wird aus irgendeinem Grund vortex_up() nicht ausgeführt, da meine globale Variable immer noch auf 1 steht, obwohl ich sie vor dem Suspend auf 0 gesetzt habe. Das führt dazu, daß die Netzwerkkarte nach dem Aufwachen erstmal nicht läuft. Nach Entfernen und neu Laden des Moduls funktioniert es wieder. Das ist jedoch keine Dauerlösung. Gruß, Eckehardt Luhm --- Eckehardt Luhm, eMail: bselu@web.de
Hallo Eckehardt, On Tuesday 24 January 2006 18:50, Eckehardt Luhm wrote:
ich habe ein Fehlverhalten in der SuSE 9.3 Personal Edition festgestellt und bräuchte nun einen Ansprechpartner mit Know-How.
Den hast Du in mir leider nicht gefunden. Aber vielleicht kann ich Dir noch ein paar Hinweise geben.
Es handelt sich dabei um die Problematik, daß Wake-On-LAN (WOL) nach einem Suspend-to-Disk nicht funktioniert.
[...] Was ich aus Deiner ausführlichen Beschreibung leider nicht herauslesen kann ist, ob diese Problematik speziell mit dem Suspend zusammenhängt. Funktioniert denn bei Dir das WOL nach einem shutdown? Ich hatte ein ähnliches Problem, bei dem WOL nach einem shutdown nicht funktionierte. Es klappte erst, nach einer Trennung vom Stromnetz oder nachdem kurz MS-DOS gebootet wurde. Ich habe das Problem nicht gelöst, aber für mich einen Workaround gefunden, der immer noch funktioniert, aber wohl für Dich nicht in Frage kommt. Falls Dich meine Problembeschreibung und Lösungsansäte interessieren: ursprüngliche Frage und Beschreibung der Lösungsversuche: http://lists.suse.com/archive/suse-linux/2004-Sep/2449.html eigene Antwort mit kurzer Beschreibung des Workarounds (LILO + DOS): http://lists.suse.com/archive/suse-linux/2004-Oct/1133.html Lösungsansatz und Berichtigung falscher Aussagen über WOL: http://lists.suse.com/archive/suse-linux/2004-Nov/1337.html Ausführliche Beschreibung: Workaround mit Fedora statt DOS: http://lists.suse.com/archive/suse-linux/2005-Mar/0330.html weiterer Ansatz zur Problemlösung (verhindere 'ifconfig..down'; Link zu einer gentoo Seite): http://lists.suse.com/archive/suse-linux/2005-Apr/0247.html Gruß, Achim
Hallo Achim!
Es handelt sich dabei um die Problematik, daß Wake-On-LAN (WOL) nach einem Suspend-to-Disk nicht funktioniert.
[...]
Was ich aus Deiner ausführlichen Beschreibung leider nicht herauslesen kann ist, ob diese Problematik speziell mit dem Suspend zusammenhängt. Funktioniert denn bei Dir das WOL nach einem shutdown?
Ja, nach einem normalen Shutdown geht WOL auch ohne meinen Workaround. Das deutet noch mehr darauf hin, daß es sich um ein Problem der Suspend-Skripte handelt.
Ich hatte ein ähnliches Problem, bei dem WOL nach einem shutdown nicht funktionierte. Es klappte erst, nach einer Trennung vom Stromnetz oder nachdem kurz MS-DOS gebootet wurde.
[...] Danke für die Info. Ich bin beim Googlen auch schon über diesen Thread gestolpert. Das hilft mir jedoch leider nicht weiter. Der Workaround, in der halt.local die WOL-Settings nochmal runterzuschreiben, funktioniert ja nur, wenn man das Problem beim Runterfahren hat. Bei einem Suspend wird halt.local jedoch nicht ausgeführt. Ich müßte also wissen, welche Skripte bei einem Suspend/Resume aufgerufen werden. Wo soll ich denn da graben?
weiterer Ansatz zur Problemlösung (verhindere 'ifconfig..down'; Link zu einer gentoo Seite): http://lists.suse.com/archive/suse-linux/2005-Apr/0247.html
In meinem Fall ist das "ifconfig ... down" sogar notwendig! Ohne den Aufruf von vortex_down() werden bei dem 3COM-Treiber die WOL-Settings gar nicht erst auf die Karte geschrieben. Gruß, Eckehardt Luhm --- Eckehardt Luhm, eMail: bselu@web.de
(weil ich doch länger für die Antwort gebraucht habe, habe ich dich vorsichtshalber ins CC: genommen) On Tue, Jan 24, 2006 at 06:50:00PM +0100, Eckehardt Luhm wrote:
Hallo,
ich habe ein Fehlverhalten in der SuSE 9.3 Personal Edition festgestellt und bräuchte nun einen Ansprechpartner mit Know-How.
Oh weh. Ob ich da der richtige bin? ;-)
Was ich soweit herausgefunden habe: Kurz bevor sich der Rechner schlafen legt, wechselt der Bildschirm auf eine andere virtuelle Konsole (ich weiß leider nicht, welche und wie ich ohne Suspend dorthin gelange). Auf dieser sind Ausgaben wie "Stopping Tasks" oder "PM: attempting to suspend to disk" zu sehen. Man sieht in diesem Screen nun, daß beim Suspend zunächst vortex_down() aufgerufen wird (ich habe im Kernelmodul 3c59x mehrere Debug-Ausgaben eingebaut). In dieser Funktion wird das WOL eingeschaltet (Funktion acpi_set_WOL() ). Gut.
Aber nur kurze Zeit später, kurz bevor der Rechner dann endgültig ausgeht, wird erneut vortex_up() ausgeführt, was dazu führt, daß das entsprechende Register in der Karte wieder gelöscht wird und anschließend WOL nicht funktioniert.
...
Ich frage mich nun, welche Skripte werden denn vor einem Suspend ausgeführt? Wo finde ich bei einer SuSE 9.3 die entsprechenden Dateien?
Das wird im kernel gemacht, die skripten bereiten nur vor.
Der eingebaute Workaround funktioniert zwar beim Suspend, beim Resume jedoch wird aus irgendeinem Grund vortex_up() nicht ausgeführt, da meine globale Variable immer noch auf 1 steht, obwohl ich sie vor dem Suspend auf 0 gesetzt habe. Das führt dazu, daß die Netzwerkkarte nach dem Aufwachen erstmal nicht läuft. Nach Entfernen und neu Laden des Moduls funktioniert es wieder. Das ist jedoch keine Dauerlösung.
Ich erklär mal kurz den suspend-ablauf: - prozesse werden angehalten - Hardware wird deaktiviert: keine DMA etc - es wird eine variable gesetzt, die sagt "wir sind gerade am suspendieren" - Es wird eine Kopie des Speicherinhalts angefertigt Der trick: der speicher, der von dieser variable belegt ist, wird nicht mit kopiert - Hardware wird wieder aktiviert - die kopie wird auf die platte geschrieben - hardware wird wieder deaktiviert - strom aus. ------ - strom wieder an - kernel bootet, einkompilierte oder schon geladene treiber werden initiali- siert - kernel merkt "oh, in der swap-partition ist ein image, wir resumen". - kernel hält alle prozesse an (z.b. aus der initrd) - image wird von der platte geladen - Hardware wird deaktiviert - image wird an den originalen platz zurückkopiert, der "boot-kernel" wird dabei überschrieben. - der kernel läuft an genau der stelle weiter, an der er in der suspend- funktion war. die "suspend-variable" ist jetzt null, also weiß der kernel daß er resumed (er soll ja nicht gleich wieder suspendieren). - die hardare wird wieder aktiviert, aber von den "alten" treibern, die vor dem suspend geladen waren. - prozesse werden wieder gestartet - fertig. Das ist etwas vereinfacht, aber im großen und ganzen paßt es schon. "Hardware wird deaktiviert" wird in der suspend funktion der treiber "Hardware wird aktiviert" in der resume funktion. Alles was du nach der "atomic copy" des Speichers machst, geht verloren, da es nicht auf die platte geschrieben wurde. Wichtig ist: die suspend und resume funktionen der Treiber werden während dem suspend mehrmals aufgerufen und während dem resume auch. Warum das bei dir jetzt nicht klappt, kann ich aus dem Bauch raus auch nicht sagen, und wenn ich mir das alles durchdenken will, wird mir eher schwindelig :-) Aber da du das prinzip der Treiber wohl gut verstanden hast, hilft dir meine Schilderung vielleicht etwas weiter. Evtl. Workarounds für dein problem könnten sein: - SUSPEND2DISK_SHUTDOWN_MODE in /etc/sysconfig/powersave/sleep. Dort kannst du "shutdown" und "platform" (default) ausprobieren. Bei "platform" wird an der stelle "strom aus" dem BIOS gesagt "wir gehen in ACPI S4", evtl. macht es da noch was böses. Bei "shutdown" wird dem BIOS gesagt "mach den strom weg", aber nix vom suspend. "richtig" ist eigentlich "platform", aber manche kisten gehen besser mit "shutdown". - du kannst versuchen, dein netzwerkkarten-modul in die initrd zu packen. Dann wird es vor dem resume schon geladen und erstmal suspendiert, das könnte deinem "modul muß neu geladen werden" problem helfen. /etc/sysconfig/kernel:INITRD_MODULES, danach "mkinitrd" aufrufen und neu booten. Es kann auch ein einfacher kernel bug sein. In diesem Fall bist du auf der linux-kernel mailingliste (oder linux-pm, dort sind die ganzen suspend-experten) besser aufgehoben wie bei mir :-) Ich hoffe, das hilft dir erstmal weiter. Tschüs und schönes Wochenende -- Stefan Seyfried
participants (3)
-
Achim Schaefer -
Eckehardt Luhm -
Stefan Seyfried