(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