Update: 9. Jänner 2009: Das Problem wurde durch ein Kernel Update behoben. Derzeit ist der aktualisierte Kernel über das -proposed Repository zu beziehen, es muss also aktiviert werden. Hier ist das passende Kommentar zum Bugreport und der Bugreport selbst. Nach einigen Tagen wird es das neue Paket voraussichtlich in die normalen Updates schaffen, es hilft also auch einfach abzuwarten und regelmäßig upzudaten. Mein Dank an die fleißigen Ubuntu-Entwickler und Upstream!
Suspend to RAM funktioniert bei meinem Centrino 2 basiertem Notebook unter Ubuntu 8.10 Linux nicht. Es handelt sich um einen Dell Latitude E6400 mit Intel GMA X4500MHD Grafikkarte.
Hier findest du meinen Installationsbericht
. Dieser Blogeintrag zeigt einen Workaround für das Suspend Problem.
Here you can find the English version of this blog entry.
Nach dem Aufwachen aus Suspend to RAM war mein Bildschirm inklusive Mauszeiger eingefrohren und bestand nur aus den grauen Flächen der Gnome-Fenster. Wie aus Berichten im Internet hervorgeht geht der Fehler vom -intel Grafiktreiber für Xorg aus, der nicht thread save zu sein scheint. Als Workaround kann man die zusätzlichen CPUs vor dem Suspend abdrehen und kurz nach dem Resume wieder aktivieren. Folgendes Skript erledigt das:
/etc/pm/sleep.d/00CPU
#!/bin/sh
# Workaround for concurrency bug in xserver-xorg-video-intel 2:2.4.1-1ubuntu10.
# Save this as /etc/pm/sleep.d/00CPU
. "${PM_FUNCTIONS}"
case "$1" in
hibernate|suspend)
for i in /sys/devices/system/cpu/cpu*/online ; do
echo 0 >$i
done
;;
thaw|resume)
sleep 10 # run with one core for 10 secs
for i in /sys/devices/system/cpu/cpu*/online ; do
echo 1 >$i
done
;;
*)
;;
esac
Das Skript muss mit Ausführungsrechten versorgt werden (sudo chmod 755 /etc/pm/sleep.d/00CPU).
Scheinbar kann nach dem Resume die automatische CPU Frequenzskalierung nicht mehr für beide CPUs eingestellt werden. Normalerweise geht dies sehr einfach mit einem Gnome Applet zur Überwachung der Prozessortaktstufen.
Diese Lösung habe ich unter folgenden Quellen gefunden, vielen Dank!
Kommentare
Fix aus den Proposed-Quellen
Hallo, wollte nochmal fragen, da ja jetzt der Fix draußen ist, ob Du das Problem mit dem Resume hinbekommen hast (bzw. ob es überhaupt bei dir auftritt). Es dauert ja echt fast an die 10 Sekunden bis das System aus dem Suspend to RAM wieder da ist - was ja nicht ganz der Sinn der Übung ist. Weißt Du ob der Fehler irgendwie schon angesprochen wurde oder ob sich da sogar schon was getan hat?
Gruß, Sebastian
Zeit für Resume
Hi Sebastian. Ich bin ansich sehr zufrieden, sowohl mit den Suspend als auch den Resume Zeiten. Dauert wenige Sekunden (vielleicht 10, eher weniger) und ich habe meinen Desktop genau da wo ich aufgehört habe. Da ich die Passwortabfrage nach Resume abgedreht habe, ist das ein enermer Vorteil zum regulären Booten.
Hallo, ja sicher, schneller
Hallo, ja sicher, schneller als richtig Hochfahren ist es natürlich. Allerdings war ich es von meinem vorigen Notebook so gewohnt, dass es aus dem Standby nach einer, vielleicht zwei Sekunden wieder voll einsatzbereit war. Bei diesem dauert es so gesehen schon sehr lange. Ich frage mich, ob es was mit den Meldungen zu tun hat, die da kurz vor dem Restart des X-Servers über den Bildschirm huschen... Na gut, wollte ich nur wissen, hätte ja sein können, dass es da was zu drehen gibt.
Sebastian
Die gute alte N-Serie
Ja klar konntest Du mir helfen, also alles nur irgendwelcher Zusatzquatsch den man nicht wirklich braucht. Dann braucht man auch nicht versuchen es zum Laufen zu kriegen :)
Zum Thema N-Serie bzw. Dell ohne Windows: Ich weiß auch nicht so recht, das gibt es zwar aber Dell tut gern so als ob nicht. Schätze die haben auch ihre Verträge mit Winzigweich. Ich hatte es da als Student bisschen einfacher, z. B. www.hfa-asknet.de stellt das einfach so zu Wahl ohne großes Gebettel.
Jedenfalls Danke für Deine Hilfe.
Frage dazu...
Funktioniert das bei Dir jetzt zuverlässig? Ich habe es genauso gemacht und - gleiches Problem. Hast Du auch, kurz bevor man wieder den X-Desktop sieht, Fehler in der Konsole? Würde mich mal interessieren... Im Bios hast Du die Option für zwei logische Prozessoren doch sicherlich aktiviert, oder?
Habe nämlich das selbe Notebook, das Problem jedoch weiterhin...
Ja, bei mir funktioniert der
Ja, bei mir funktioniert der Workaround völlig zuverlässig. Im BIOS habe ich nichts umgestellt und auf der Konsole werden ein paar Meldungen für ca. eine halbe Sekunde angezeigt. Irgendetwas mit PM failed to resume in der letzten Zeile. Geht aber zu schnell es genau zu lesen.
Bist du sicher, dass das Script funktioniert, hast du die Berechtigungen gesetzt? Testen kannst du es auch indem du es ausführst und in der Gnome Systemüberwachung nur noch eine CPU siehst.
Da steckt doch der Wurm drin...
Ich habe es gestern ausprobiert, genau nach deiner Anleitung. Mehrfach versucht, immer wieder das übliche Hängenbleiben. Und jetzt heute Morgen (oder eher Mittag ;) ) gehts auf einmal. Dreimal hintereinander... Merkwürdig. Na ja, dann hoffe ich einfach mal, dass das so bleibt.
Ich hab noch ein paar Fragen, wenn Du so nett bist, ansonsten ignoriere sie einfach. Das Problem ist, dass ich das Notebook als n-Series gekauft habe, also ganz ohne Windows (eigentlich ist das ja gut, aber mangels Doku manchmal auch nervig; auf den Dellseiten finde ich einfach keine Antwort).
1. Die Fn-Funktion auf der F3-Taste, so eine leere Batterie: Hat die einen Effekt? Unter Linux bei dir? Oder passiert da was hardwareseitig?
2. In etwa gleiche Frage zu F7 und F8 und zu "DCP" noch die Frage, was das denn überhaupt ist.
3. Und zuletzt noch die kleine Taste neben dem WLAN-Schieber: Was macht das, ist das unter Linux zum Laufen zu kriegen (falls es denn was macht, was auch einen Sinn hat :) )?
Vielen Dank schon mal, gut jemanden gefunden zu haben, der das gleiche Notebook mit dem gleichen System nutzt.
Dell Latitude
Freu' dich bitte nicht zu früh, bei mir hat es, jedoch vor dem Workaround, auch oft mehrere Male funktioniert. Nur um beim 10x hängen zu bleiben. Sollte das bei dir wieder passieren kannst du auch die "sleep" time im Script erhöhen. Dann kannst du direkt nach dem Resume im Systemmonitor nachsehen ob du tatsächlich nur eine CPU aktiv hast.
Finde ich interessant, dass du das Notebook ganz ohne Windows bekommen hast. Ich habe bei der Hotline mehrfach nachgefragt und musste als billigste Variante immer noch Vista Home Basic nehmen.
Nun zu deinen Fragen:
Naja, ob ich dir sehr weiterhelfen habe können weiß ich nicht.
Ach so...
Sorry, ich bin es noch einmal: Habe jetzt festgestellt was der Fehler sein mag: Wenn ich das Script so starte, scheint er ein Problem in der 5. Zeile zu haben, also mit dieser Variable... Ist das normal? Ist die beim Suspend-Vorgang gesetzt? Bei mir scheinen immer beide CPUs vorher und nachher zu laufen. Ist mir auch nicht ganz klar: Läuft der Rechner denn nach dem Suspend nur noch auf einer CPU?
Gruß, Sebastian
Das passt schon...
das Skript bekommt einen Parameter übergeben, um zu wissen was es tun soll.
Versuche als alternative Lösung einmal Andy Whitcrofts Kernel, dann brauchst du auch das Skript nicht mehr:
http://people.ubuntu.com/~apw/lp276943/
Die Erklärung findest du im Bugreport ganz unten:
https://bugs.launchpad.net/bugs/276943
Viel Erfolg,
Robert
Danke für den Tipp. Scheint
Danke für den Tipp. Scheint jetzt wirklich zuverlässig zu laufen. Nur dass das Aufwachen nach wie vor fast 10 Sekunden dauert. Na mal sehen, ob sich da noch was richten lässt...
Kommentar hinzufügen