Arch Linux

pm-suspend suspendet und resumet nicht richtig / gar nicht

[gelöscht]

Huhu,

ich betreibe Arch auf einem IBM X31 und habe leichte Probleme mit der suspend to ram Funktion.

Vorerst: Arch ist meine erste Distribution nach ein paar Monaten Ubuntu auf meinem Desktop PC. Das wollte ich meinem kleinen X31 allerdings nicht zumuten 🙂. Soweit habe ich alles halbwegs selbst durch Wiki/Google/Leute im ICQ nerven eingerichtet und bis auf suspend to ram laeuft alles (auch suspend to disk), allerdings weiß ich nicht, wie ich dieses Problem angehen soll :/.

Wenn ich meinen Laptop nun also in den standy modus schicken moechte, scheint dies auch so halbwegs zu funktionieren, allerdings bleibt der Monitor "schwarz beleuchtet" an. Wenn ich nun ein ACPI Event schicke, um den Laptop zu wecken, reagiert der Laptop, der Bildschirm geht kurz aus und wieder an, bleibt dann allerdings in diesem schwarz, beleuchteten Zustand. Mehr passiert nicht.

Aus dem Log kann ich irgendwie auch nichts gewinnen:

[topha@topha ~]$ sudo cat /var/log/pm-suspend.log 
Fr 4. Jan 17:09:39 CET 2008: running suspend hooks.
===== Fr 4. Jan 17:09:39 CET 2008: running hook: /usr/lib/pm-utils/sleep.d/00clear =====
===== Fr 4. Jan 17:09:39 CET 2008: running hook: /usr/lib/pm-utils/sleep.d/01grub =====
===== Fr 4. Jan 17:09:39 CET 2008: running hook: /usr/lib/pm-utils/sleep.d/05led =====
===== Fr 4. Jan 17:09:39 CET 2008: running hook: /usr/lib/pm-utils/sleep.d/10NetworkManager =====
===== Fr 4. Jan 17:09:39 CET 2008: running hook: /usr/lib/pm-utils/sleep.d/11netcfg =====
===== Fr 4. Jan 17:09:39 CET 2008: running hook: /usr/lib/pm-utils/sleep.d/20video =====
kernel.acpi_video_flags = 0
===== Fr 4. Jan 17:09:39 CET 2008: running hook: /usr/lib/pm-utils/sleep.d/49bluetooth =====
===== Fr 4. Jan 17:09:39 CET 2008: running hook: /usr/lib/pm-utils/sleep.d/50modules =====
===== Fr 4. Jan 17:09:40 CET 2008: running hook: /usr/lib/pm-utils/sleep.d/55battery =====
===== Fr 4. Jan 17:09:40 CET 2008: running hook: /usr/lib/pm-utils/sleep.d/65alsa =====
===== Fr 4. Jan 17:09:40 CET 2008: running hook: /usr/lib/pm-utils/sleep.d/90clock =====
===== Fr 4. Jan 17:09:41 CET 2008: running hook: /usr/lib/pm-utils/sleep.d/94cpufreq =====
===== Fr 4. Jan 17:09:41 CET 2008: running hook: /usr/lib/pm-utils/sleep.d/95led =====
===== Fr 4. Jan 17:09:41 CET 2008: running hook: /usr/lib/pm-utils/sleep.d/99video =====
Fr 4. Jan 17:09:41 CET 2008: done running suspend hooks.

Hat vielleicht jemand einen Tipp fuer mich, wo ich ansetzen muss um das Problem zu loesen?

Evtl. noch von belangen: Ich benutze den freien xf86-video-ati Treiber.

Wenn noch Informationen benoetigt werden, einfach nachfragen 🙂.

fs4000

Hast du schonmal einen direkten Aufruf ohne Vorbereitungen versucht?
echo -n mem > /sys/power/state
(als root)
Bei mir klappt suspend to disk ohne alle Vorbereitung. Suspend to ram scheint aufgrund eines BIOS-Bugs nicht zu funktionieren.
Der Rechner schaltet ab, aber wenn ich ihn wieder einschalt, fährt er neu hoch.
Windows 98 und XP schaffen es aber.

GerBra

Topha schrieb Wenn noch Informationen benoetigt werden, einfach nachfragen 🙂.

Das Modul thinkpad_acpi ist geladen?
Ich habe für meinen T22 in der /etc/modprobe.conf:
options thinkpad_acpi hotkey=enable,0xffffff experimental=1

Bei mir funktioniert Suspend ohne Problem.

[gelöscht]

Wenn ich:

echo -n mem > /sys/power/state

eingebe, passiert genau das selbe, wie nach pm-suspend.

thinkpad_acpi hab ich fest einkompiliert, ich benutze also einen eigenen kernel 🙂.

options thinkpad_acpi hotkey=enable,0xffffff experimental=1
bringt auch nix, aber ist bei einem einkompiliertem thinkpad_acpi die /etc/modprobe.conf ueberhaupt von Bedeutung?

GerBra

Vergiß das mit dem thinkpad_acpi 😉

Hier ist das Problem beschrieben:
http://thinkwiki.org/wiki/Problem_with_LCD_backlight_remaining_on_during_ACPI_sleep
Übrigens immer einen Bookmark wert (für deinen x31):
http://thinkwiki.org/wiki/Category:X31

Die Lösunf scheint also, per: radeontool light off das Backlight auszuschlaten vor dem
Suspend. Und es gibt dabei scheinbar einen Unterschied ob X läuft oder nur die
Konsole.

Schau dir mal diesen Wiki-Beitrag an:
http://wiki.archlinux.org/index.php/Pm-utils#Creating_your_own_hooks
Da wäre jetzt der Ansatz, dieses radeontool light off bei Arch unterzubringen.
Das Beispiel-Skript bietet ja eigentlich schon alles:
In suspend mußt du radeontool light off unterbringen (evtl. kombiniert mit dem
was im Thinkwiki-Beitrag über vorher in die Konsole wechseln steht).
In resume dann das Backlight wieder einschalten.

Wenn du damit Probleme haben solltest kann ich dir gerne versuchen zu helfen, obwohl
ich keine ATI zum gegentesten haben (oller savage chipsatz).

Zum prinzipiellen Austesten (ob das: radeontool light off überhaupt den Fehler beseitigt)
könntest du deinen XServer beenden, als root einen Suspend machen mit:
radeontool light off && pm-suspend
Nach dem Aufwachen mußt du entweder "blind" eingeben:
radeontool light on
oder halt zur Not warmstarten. Aber du weißt wenigstens ob du auf dem richtigen
Weg bist.

GerBra

Gerade mal tiefer in pm-utils reingeschaut. Evtl. genügt es bei dir schon:

DISPLAY_QUIRK_RADEON_OFF="true"

in die /etc/pm/config.d/config einzutragen (die Datei mußt du erstellen).
Weil:
in /usr/lib/pm-utils/sleep.d/20video ist eigentlich schon alles vorbereitet.

[gelöscht]

Ui, noch eine Antwort 🙂.
Hatte mir eben das radeontool Paket gebaut, X beendet und den Laptop in den standby geschickt. Resultat: Bildschirm ging / blieb komplett aus. Soweit so gut: Nach dem Wecken ließ sich der Bildschirm aber durch blindes eintippen von radeontool light on nicht wieder anschalten. Auch ein blind getipptes "reboot" blieb ohne Folgen, also scheint das Problem nicht nur das Einschalten des Monitors zu sein.

DISPLAY_QUIRK_RADEON_OFF=true bewirkt auch, dass der Monitor aus geht/bleibt. Wecken laesst sich der Laptop aber trotzdem nicht 🙁.

Hab mir die /usr/lib/pm-utils/sleep.d/20video grade auch mal angeschaut. Das scheint ja auch auf radeontool aufzubauen, lieg ich da richtig?

GerBra

Ja, das setzt radeontool ein, beim 20video wird es halt ausgeschaltet, beim 99video
wieder eingeschaltet.

Mit "Wecken" meinst du aber schon die Betätigung des Einschaltknopfs? 😉

Evtl. noch mal die /var/log/pm-suspend.log mitbeobachten auf Meldungen.

Ich würde auch zum testen mal alles an Module entladen was gerade nicht nötig ist,
z.B. wlan,usb,usw.

Kannst du evtl. von einem anderen Rechner versuchen den Laptop anzupingen nach
dem Aufwachen? Oder schauen ob Tastatur-LEDs etc. noch angehen, STRG+ALT+ENTF
noch funktioniert? Also ob der Rechner noch "lebt".

[gelöscht]

Mit wecken mein ich halt irgendein ACPI Event 🙂. Der Power Knopf bringt aber auch keine Aenderung (zur Sicherheit grade noch einmal ausprobiert *g*).

Die Tastatur LEDs reagieren danach nicht mehr, ebensowenig wie Strg+Alt+Entf.
Anpingen tu ich ihn morgen mal, keine Lust jetzt noch aus dem Bett aufzustehen 😉.

Module entladen wird schwierig, da ich eigentlich alle fest einkompiliert habe :lol:. Oder ist das trotzdem moeglich?

Melde mich morgen nach dem anpingversuch noch einmal, aber bin mir recht sicher dass der Rechner "tot" is :/.
Gute Nacht 🙂

[gelöscht]

So, grade den anpingversuch gestartet -> Lässt sich nicht mehr anpingen.
Allerdings werde ich aus dem Log auch nicht wirklich schlau. Es wird doch auch gar kein Hook ausgeführt, der das Netzwerk wieder starten lässt, oder seh ich das falsch?

GerBra

Ist beim Netzwerk IMHO auch nicht nötig, ein statisch konfiguriertes läuft sowieso weiter,
bei dynamischem sollte sich der dhcp-Client ggf. um ein neues Lease bemühen.
Lediglich für den Networkmanager sehe ich einen.

Ist dieses Verhalten des "Einfrierens" denn jetzt neu nach der Aktivierung der ATI-Quirks,
oder was das (wenn der Vorgang vergleichbar ist) auch ohne schon der Fall?

Könntest du das ggf. mal mit dem Arch-Standard-Kernel versuchen?

Ansonsten bin ich mangels "Objekt zum Anfassen" so langsam überfragt...

[gelöscht]

Nein, vorher ist er auch schon eingefroren.

Habs grad mit standard Kernel probiert und tadaa, es lief. Allerdings sind natuerlich auch keine Module geladen worden und ich habs "nur" unter der Konsole probiert, da ich nicht bis X gekommen bin

Fehler: für /dev/hda3
 FILESYSTEM CHECK FAILED
The superblock could not be read or does not describe a correct ext2 filesystem

Kein Wunder, ist ja auch ne ext3 🙂 (btw: meine root partition)

Aber naja, ist denk ich mal nicht allzu wichtig, immerhin laeuft es da :\

GerBra

Das ist doch wenigstens ein Ansatz 😉

Müßtest halt mal die unterschiedlichen Kernel-Configs diffen, ob du evtl. "nur" etwas
vergessen hast. Oder das Modulare hat hier wirklich den Vorteil (könnte ich mir bei
manchen Sache sogar vorstellen, da halt vor dem Suspend Module+hardware halt
wirklich entladen/"deaktiviert" werden kann und beim Resume halt wieder initialisiert.

[gelöscht]

Hm, das bringt schon einen ganz schoenen Batzen an Daten mit sich, ziemlich genau 3941 Zeilen 🙂. Gibt es denn irgendetwas, worauf ich gesondert achten sollte? Habe jetzt diff ganz normal aufgerufen, also

diff /usr/src/linux/.config /usr/src/linux-2.6.23-ARCH/.config

Oder gibt es da noch irgendwelche special uberparameter? :lol:

GerBra

Wenn das .config für Arch das "unkonfigurierte" ist, dann macht das wenig Sinn.
Du müßtest deine .config gegen die /boot/kconfig26 diffen.
Allerdings dürfte das wenig Aussagekraft haben wenn du weitgehend alles in den
Kernel eingebaut hast.

Was für einen Kernel hattest du den bzw. warum hast du einen eigenen Kernel
gebaut? Wenn du weißt, was du wo geändert hast ist das evtl. gegen die
Arch-kconfig besser nachvollziehbar.

Oder noch anders: was spricht gegen den Arch Standard-Kernel?

[gelöscht]

Ich hatte den normalen Arch Kernel aus dem aktuellstem ISO,
der selbstgebackene ist ein 2.6.23.9er Kernel.

Hm, ja, das mit dem Kernel war so eine "gib mal her!" Aktion von nem Kumpel, ich saß halt daneben und hab froehlich geguckt, wie er mir ne Kernelkonfig bastelt 🙂.
Hat in sofern etwas gebracht, dass mein Arch jetzt so in ~25 Sekunden bis zum Login Manager hochfaehrt. Vorher hats doch schon bedeutend laenger gedauert (bilde ich mir zumindest momentan ein 🙂).

diff gegen /boot/kconfig26 kommt uebrigens zum selben Ergebnis :/.

[gelöscht]

Hm, also hier stoße ich nun auf meine Grenzen, habe die beiden Kernelconfigs folgendermaßen verglichen:

diff /boot/kconfig26 /usr/src/linux/.config > /home/topha/Desktop/diff | grep =y

Reduziert das ganze schonmal auf ~500 Zeilen 😉. Jedoch sehe ich nichts, was evtl benoetigt werden koennte um richtig zu suspenden. Ist diese diff Ausgabe denn ueberhaupt brauchbar? Oder hab ich da Mist verzapft?🙂

GerBra

Deswegen schrieb ich ja daß das Diff wenig SInn macht - du vergleichst ja nicht Gleiches
mit Gleichem - bei nur minimalen Änderungen.

Ich würde mir beide Configs per less od. Editor vornehmen und diese nebeneinander
durchscrollen. Hauptansatzpunkte wären da sicher der Block"Power management options
(ACPI, APM)" oder halt von Anfang an bis so die Treiber losgehen:
"(PCCARD(PCMCIA/CardBus) support."

Und da halt v.a. schauen ob bei einer Version eine Option ein- oder abgeschaltet ist, egal
ob eingebaut(y) oder als Modul(m).
Vielleicht kannst du ja auch deinen Kumpel nochmal ins Boot holen 😉

Und es kann halt auch sein, daß ein korrektes Suspend mit einem nicht-modularisiertem
Kernel eben nicht geht - Hardware funktioniert u.U. halt nur (wieder) korrekt wenn
der Treiber neu geladen wird - was ja nur bei Modulen geht.

Ist denn der Unterschied beim Booten so groß? Die "längere" Bootzeit kommt ja v.a.
durch udev, was versucht die Hardware zu erkennen. Das kann man ja in der rc.conf
auch abstellen, man muß dann halt die benötigten Module explizit laden.
Wobei mich Bootzeit recht wenig stört (ist für mich nicht das Feature was Arch gegen
andere Distris auszeichnet). Ich schalte ein und gehe einen Kaffee holen o.ä.

[gelöscht]

Ach, was solls, ich glaub ich steig wieder auf den normalen Kernel um, ich kann den Lappy ja einfach immer schlafen schicken :lol:.

Jedenfalls vielen Dank fuer deine Hilfe, auch wenn das Problem (noch) nicht wirklich geloest ist, bin ich doch ein ganzes Stueck weiter gekommen 🙂.

[gelöscht]

Ok, es lag einzig und allein am radeon framebuffer. Mein Kumpel meinte, wenn er tippen müsste warum es nicht geht, würde er auf den fb tippen. Rauskompiliert und schon gings.
Dacht ich mir schreibs hier nochmal rein, falls jemand das selbe Problem bekommt 🙂.

Nächste Seite »