R31 - Suspend to RAM unter Linux

T

thorfdbg

Active member
Registriert
14 Juni 2013
Beiträge
1.016
Hallo miteinander,

ziemlich antike Hardware, zuzugegeben, aber ich habe mal einen wiklich alten R31 mit Linux ausgestattet. Für das Alter läuft das Gerät noch recht rund. Nach etwas Gebastel funktioniert fast alles - bis auf Suspend2Ram. Habe schon die ganzen Kernel-Debugging Links durch, aber das Gerät lässt sich nicht zum Aufwecken bewegen. Nach dem Resume klackert das CDRom kurz, danach bleibt der Schirm schwarz und die Maschine ist vollkommen unansprechbar. Weder über Tastatur noch Netzwerk lässt sich das Gerät zu einer Reaktion bewegen, nur hart ausschalten hilft.

Hatte Suspend2Ram beim R31 grundsätzlich nicht funktioniert, oder ging das mal unter $OTHER_OS? Gibt es eventuell noch einen Trick unter Linux, wie man das Gerät ansonsten zur Mitarbeit bewegen kann

Kernel ist aktuell. BIOS ist so aktuell wie geht (3.110).
 
Das ACPI im R31 dürfte eigentlich kein Problem bereiten. Interessanter und hilfreich wäre auf jeden Fall, wenn wir wüssten, mit welcher Distribution und Version Du arbeitest.
 
*Wie* bringst du das Gerät in den S3?

Wie Morns geschrieben hat, ist die Hardware unproblematisch. Meist kommt sowas aber von Wlan Karten oder irgendwelchen PCMCIA Karten, die man dann vor dem Suspend deaktivieren muss.

Also: welche Hardware genau ist da drin/dran?
 
Laut Wiki hat das R31 die Intel 830MG Grafik. Wenn dem so ist, dann handelt es sich eventuall um dasselbe Problem wie bei meinem X30:

https://bugs.freedesktop.org/show_bug.cgi?id=49838

Eine Zeit lang sah es danach aus, als würden sich die Entwickler des Problems annehmen, mittlerweile habe ich aber jegliche Hoffnung verloren :(

Bei FreeBSD hat man z.B. noch den alten nicht-KMS Treiber, sodass Suspend ohne Probleme funktioniert. OpenBSD wollte ich auch mal ausprobieren, komme aber aus Zeitmangel leider nicht dazu.
 
Myon schrieb:
Eine Zeit lang sah es danach aus, als würden sich die Entwickler des Problems annehmen, mittlerweile habe ich aber jegliche Hoffnung verloren :( Bei FreeBSD hat man z.B. noch den alten nicht-KMS Treiber, sodass Suspend ohne Probleme funktioniert. OpenBSD wollte ich auch mal ausprobieren, komme aber aus Zeitmangel leider nicht dazu.
Zum Vergrößern anklicken....
Also, das ist *nur* ein roher R31, ohne WIFI, und der PCMCIA-Slot ist leer. Die Graphik ist wie gesagt die 830GM. Kernel ist ein 3.15.0+rc7, nachdem ich den Kernel-Entwicklern der Intel-Graphik gehörig auf die Füße getreten bin, funktioniert in diesem Seitenbranch die Intel-Graphik endlich auch korrekt. Hat nur ein Jahr gedauert... Leider ist *der* Teil nicht im aktuellen Kernel drin.

Aber wer mag: Bitte, bitte *AUCH* einen Bugreport schicken (an intel-gfx@lists.freedesktop.org) und darauf referenizieren, dass es die Fixes im "alm_fixes5" Branch bereits gibt, und sich endlich mal jemand überwinden soll, die zu mergen. *Sigh*.

Andere Geschichte, wer mehr erfahren mag -> PM. Momentan nehme ich mich des Problemes an, die Kernelentwickler zu treten und mit Bugfixes zu füttern (ist nicht mein Branch, nur das Resultat meiner Aktivität).

Soweit, so gut - klappt alles schon sehr fein, bis auf dieses verd*mmte Suspend2Ram. Jetzt sollte man meinen, es wird wohl der i915-Treiber sein, der da spukt. Ist aber nicht. Auch ohne den i915-Kerneltreiber, ohne KMS, ohne drm und nur mit der Textkonsole erhängt sich der Rechner beim Resume.

Habe schon alle Treiber (bis auf den e100 Netzwerktreiber, irgendwie muss ich ja auf die Kiste kommen) aus dem Kernel geschmissen. Trotzalledem... nichts zu wollen, die Kiste startet nicht mehr, nicht ein einziges Ping kommt durch, totale Funkstille.

Im Bios gab's noch eine Option, Suspend zu deaktivieren wenn etwas im PCMCIA-Slot steckt. Da steckt nichts, habe diese Option aber abgewählt. Hilft nicht die Bohne....

Suspend2Disk geht übrigens, vollkommen problemlos. *Das* ist nicht das Problem. Soll ich mal FreeBSD probieren? Wo würde man eine InstallationsCD finden? (Nein, ich brauche die Kiste nicht wirklich. Ist aber ein feines Museumsstück, und mir tut es irgendwie im Herzen weh, wenn man das Teil nicht vernünftig zum Laufen bekommt).
 
Zuletzt bearbeitet von einem Moderator:
Später... FreeBSD ist installiert. Wenn ich die man-page richtig verstehe, bekommt man das System mittels "zzz" in den Suspend. Resultat ist leider identisch zu Linux: Schwarzer Schirm, nicht reagierendes System. Bummer! Bios ist übrigens 3.110, das "neueste", was ich finden konnte. Noch Ideen?
 
Hey, vielen Dank für den Tipp mit alm_fixes5 Branch. Ich habe den Hinweis jetzt zu meinem Bugreport hinzugefügt, vielleicht tut sich dann was :rolleyes:

Bei meinem X30 liegt es wirklich an der Intel-Grafik, d.h. mit dem Vesa-Treiber funktioniert Suspend unter Linux ohne Probleme. Bei deinem R31 scheint das Problem tiefer zu sitzen, an der Grafik allein liegt es jedenfalls nicht. Hast du schon mal git-bissect

https://www.kernel.org/pub/software/scm/git/docs/git-bisect-lk2009.html

probiert? Vorausgesetzt, du findest einen alten Kernel bei dem Suspend noch funktioniert hat, kann man mit git-bissect recht zuverlässig herausfinden, welcher commit das Problem verursacht. Das ist natürlich auch recht aufwändig, da man bei jeder Bissektion den Kernel neu kompilieren muss.
 
Myon schrieb:
Bei deinem R31 scheint das Problem tiefer zu sitzen, an der Grafik allein liegt es jedenfalls nicht. Hast du schon mal git-bissect

https://www.kernel.org/pub/software/scm/git/docs/git-bisect-lk2009.html

probiert? Vorausgesetzt, du findest einen alten Kernel bei dem Suspend noch funktioniert hat...
Zum Vergrößern anklicken....

Ja,Kernel-Bugs habe ich schon durch Bisektion gelöst und gefunden, insofern ist mir der Weg nicht unbekannt (damals im yentaa-PCMCIA, war ein Wochenende Arbeit), allerdings hatte ich hier gehofft, dass ich auf jemanden stoße, der mir vielleicht einen Startpunkt für die Bisektion gibt ("hat bei mir mit Kernel XY noch funktioniert"), oder mir sagt, dass es hier definitiv ein BIOS-Bug gibt, oder dass das Problem im BIOS ABC eingeführt wurde. 3.2.0 (Debian Stable) geht schon nicht mehr, FreeBSD selbst im Text-Modus scheitert. )-: Falls jemand einen funktionierenden R31 hat, könnte man ja zumindest mal die BIOS-Parameter vergleichen (obwohl ich schon vieles durchprobiert habe, eventuell bin ich etwas blind.).
 
Wenn ich den Thread nochmal hervorholen darf: Nach einiger Recherche gab es nur einen Artikel, bei dem Ubuntu 8.0.4 als "funktionierend mit Suspend 2 Ram" angegeben wurde. Leider bei mir nicht. Ich dachte ebenso, dass ich beim Verzicht auf acpi und Umschwenken auf apm mehr Erfolg haben würde, nur der Kernel ist der Meinung, dass das R31 kein APM-Bios habe. Hat man das beim neuesten Bios-Update herausgeworfen?

Ebenso ist es leider nicht richtig, dass das ACPI vom R31 fehlerfrei sei. Ich habe jetzt mal die ganze DSDTs auseinandergefrickelt und die Fehler händisch behoben, insbesondere einen im Wakeup-Call (\_WAK heißt das wohl in der DSDT). Leider ohne Erfolg, resume aus suspend2ram klappt immer noch nicht, trotz korrigierter DSDT. Ebenso hilft es nicht, dem ACPI unter Linux unterzujubeln, es würde unter Windows laufen. Das ACPI kennt hier "Windows", "Windows NT" und die Müllenium-Edition, keine von denen erbringt einen Erfolg beim Resume - hängt so oder so.

Noch jemand sachdienliche Hinweise, bevor ich aus rein wissenschaftlicher Neugierde mal ein Windows98 auf die Kiste schiebe und gucke, was dann mit dem Suspend passiert?

Ist das eigentlich richtig, dass der R31 von Acer für IBM gebaut wurde?
 
thorfdbg schrieb:
Ist das eigentlich richtig, dass der R31 von Acer für IBM gebaut wurde?
Zum Vergrößern anklicken....
Das wäre mir neu.

Dass das R31 kein APM kann, wundert mich nicht, da bereits ab Baujahr 2000/2001 APM kaum noch Verwendung fand. Unter Linux startete zu jener Zeit das swsusp-Projekt, das versuchte, ACPI unter Linux für Standby und Ruhezustand zu implementieren. Erst, als etwa im Jahre 2002 u.a. Intel und IBM diesem Projekt beitraten, kam erst richtig Bewegung ins Spiel, da war das R31 schon auf dem Markt und es dauerte noch eine Weile, bis ACPI-Kernel wirklich stabil liefen.
 
Jetzt nochmal ein Update von mir, ich kann's ja nicht lassen.

Also, der R31 *hat* ein APM-Bios. Das Problem ist nur, dass dieser #*$@!! grub2 die entsprechenden Informationen nicht an den Kernel weiterleitet und man ihn dazu überreden muss, überhaupt nach apm zu gucken.

So geht's: Im grub2 sollte man in der Boot-Zeile "linux" durch "linux16" ersetzen, ferner die Kommandozeilenparameter "acpi=off apm=on" setzen, dann wird auch das APM-Bios verwendet. Ja, "linux16" statt "linux" *muss* sein, sonst gibt's kein APM. Warum auch immer...

Und siehe da! Suspend2Ram funktionert.

Irgendwie.

Will sagen: Die Kiste legt sich schlafen, lässt sich auch aufwecken, aber der Lüfter rödelt weiter. Irgendwie unpraktisch. Zweites Problem ist, dass ich damit Suspend2Disk nicht mehr zum Funktioneren bekomme, und das dritte Problem ist, dass der i915-Intel-Treiber für die Graphik ohne ACPI nicht so recht will. "no such device" sagt mir das Modul.

Ich gucke mal, was die Kernel-Developper dazu zu sagen haben, "lspci" listet nämlich brav den Chipsatz, egal ob apm oder acpi.

Das Problem mit dem Lüfter scheint kein neues zu sein, wird auch bei alten Distributionen erwähnt. Habe mal spaßenshalber Susie 9 ausprobiert - hier noch mit altem i810-Treiber - und ja, auch hier bleibt der Lüfter laufen.
 
Jetzt wohl das finale Update... nach etlichem Geforsche stellte sich heraus, dass das apm-Bios gar nicht in Suspend2RAM (S3-State) geht, sondern nur in den Suspend-State (S1-State). Wie ich dann weiterhin feststellen konnte, funktioniert "suspend" unter ACPI vollauf korrekt, nur läuft eben der Lüfter weiter. Letztendlich habe ich dem System eine gefixte ACPI-Tabelle untergeschoben, die nicht nur korrekt durchcompiliert, sondern auch die Information über den defekten S3-Zustand nicht mehr enthält. Resultat ist jetzt ein vollständig korrekt funktionierendes R31, allerdings ohne Suspend2Ram, sondern nur mit Standby und Suspend2Disk. Das ist immer noch weniger als XP hinbekommt, aber viel besser wird es vermutlich nicht werden.
 
So, vielen Dank! Alles erledigt. Im R31-Wiki findet sich die reparierte DSDT für den R31 und ebenso der fertig compilierte Kernel für Debian, sowie die Kernel-Sourcen dafür. Damit sollte auf dem R31 eigentlich alles funktionieren, inklusive Standby und Graphik.
 
Vielen Dank.

Zur Info:
Die im Wiki-Artikel verlinkten Downloads liegen auf meiner Dropbox.
 
http://thinkwiki.de/R31#i830_Graphik
Code: 
    linux-image-3.15.0-rc7%2B_3.15.0-17_i386.deb ein passend gepatchter Kernel für das R31, mit dem die i830-Graphik korrekt funktioniert.
    linux.tar.xz Kernel-Sourcen des Kernels.

Wäre es nicht besser, anstatt den kompletten Kernelquellcode anzubieten, einfach nur den Patch für den Grafiktreiber zu verlinken? So
könnte man den Patch auch auf neuere Versionen anwenden, was aktuell kaum möglich ist.
 
Myon schrieb:
http://thinkwiki.de/R31#i830_Graphik
Wäre es nicht besser, anstatt den kompletten Kernelquellcode anzubieten, einfach nur den Patch für den Grafiktreiber zu verlinken? So
könnte man den Patch auch auf neuere Versionen anwenden, was aktuell kaum möglich ist.
Zum Vergrößern anklicken....

Der Patch ist jetzt sowieso im Kernel drin. Für den 3.17 Release hat es wohl nicht mehr gereicht, aber ich hoffe, dass es jetzt für den 3.18er zeitig genug ist. Zur Not muss ich das nochmal anschieben. Weil's so schön ist, funktionieren jetzt im 3.17er die FN+Tastenkombinationen (Thinklight, Heller/Dunkler) nicht mehr. Patch habe ich schon, jetzt muss ich dummerweise *noch* einer Gruppe von Kernel-Hackern in den Hintern treten... Seufz.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
  • ok1.de
  • ok2.de
  • thinkstore24.de
  • Preiswerte-IT - Gebrauchte Lenovo Notebooks kaufen

Werbung

Zurück
Oben