Installation¶

pm-utils ist in der Standardinstallation von K|X|Ubuntu immer enthalten. Bei einer Minimalinstallation oder anderen Ubuntu-Derivaten muss ggf. das Paket

• pm-utils

installiert ^[1] werden. Die Dokumentation findet man unter /usr/share/doc/pm-utils.

Mit pm-utils werden u.a. folgende Verzeichnisse und Dateien installiert. Dunkler hinterlegt sind die Namen der Dateien und Verzeichnisse, die vom Benutzer verwendet werden bzw. deren Inhalte von Benutzer verändert werden dürfen. Heller hinterlegt sind die Dateien und Verzeichnisse, die man nur dann braucht, wenn man sich mit Details beschäftigen möchte.

pm-utils - Hooks¶

"Hooks" sind pm-utils-Skripte, die bei SUSPEND- und RESUME-Vorgängen abgearbeitet werden:

• beim SUSPEND-Vorgang werden die Hooks abhängig von der SUSPEND-Art mit dem Parameter suspend respektive hibernate in der alphabetischen Reihenfolge aufgerufen.

• beim RESUME-Vorgang werden die Hooks in der umgekehrten Reihenfolge abgearbeitet, wobei sie beim RESUME_from_STR mit dem Parameter resume aufgerufen werden, beim RESUME_from_STD hingegen mit dem Parameter thaw.

Die Parametrierung der Aufrufe ermittelt pm-action automatisch ohne Zutun des Benutzers.

SUSPEND- und RESUME mit pm-utils¶

echo -n "platform" > /sys/power/disk 
echo -n "disk" > /sys/power/state  

Sind SUSPEND/HIBERNATE möglich?¶

Für diese Prüfung verwendet man das Skript pm-is-supported aus dem Paket pm-utils. Das Paket hal hängt u.a. vom Paket pm-utils ab, sodass pm-utils i.d.R. installiert sein wird.

• In einer Konsole diesen Einzeiler eingeben:
  

  echo; for i in --suspend --hibernate --suspend-hybrid; do pm-is-supported $i && echo "$(echo $i | tr [:lower:] [:upper:] | tr -d -) is 
  supported"; done; echo 

• Alternativ: dieses Skript speichern, ausführbar machen und ausführen (läuft auch als nicht privilegierter Benutzer):
  

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

  #!/bin/bash # check if we can test acpi power states with pm-is-supported if ! which pm-is-supported 1>/dev/null then echo echo "pm-is-supported not found" echo "Please install the package pm-utils if not installed" echo echo "Otherwise check \$PATH" echo "pm-is-supported should be in /usr/bin/" echo exit 1 fi # a new line echo # check POWER MANAGEMENT MODES # for MODE in suspend hibernate suspend-hybrid # do # pm-is-supported --$MODE && echo "Kernel supports $(echo $MODE | tr [:lower:] [:upper:] ) " # done pm-is-supported --suspend && echo "Kernel supports SUSPEND (SUSPEND to RAM)" pm-is-supported --hibernate && echo "Kernel supports HIBERNATE (SUSPEND to DISK)" pm-is-supported --suspend-hybrid && echo "Kernel supports HYBRID-SUSPEND (to DISK & to RAM)" # a new line echo exit 0

Die Ausgabe nennt die möglichen Energiesparmodi, die das System im aktuellen Zustand erreichen kann.

Was ist das Ziel?¶

Nachdem festgestellt wurde, ob und welche Energiesparmodi erreicht werden können, muss man die Entscheidung treffen, ob diese Energiesparmodi über Kernelspace oder Userspace (zum Beispiel mit Hilfe von uswsusp) erreicht werden sollen.

STD auf SWAP-Partition¶

Das ist der Standardfall: Eine aktive SWAP-Partition im System, keine Fehler

Hat man nur eine SWAP-Partition und keine Fehler im System, d.h. die SWAP-Partition ist korrekt definiert und aktiv, dann sollte man so verfahren:

1. Partitionsname der SWAP-Partition z.Bsp. aus der Ausgabe von
   

   sudo fdisk -l 

   
   ablesen (nach "Swap" suchen und /dev/xxxy merken!)

2. Partitionsname bzw. UUID-Identifier der SWAP-Partition z.B. aus /etc/fstab ablesen:
   

   grep swap /etc/fstab | grep -v 

3. UUID-Identifier der SWAP-Partition ("/dev/xxxy" von oben) aus der Ausgabe
   

   ls -l /dev/disk/by-uuid 

   
   ablesen.

4. Die abgelesenen Informationen sollten übereinstimmen! Sonst bei Sonderfälle unten weitermachen

5. Überprüfen, ob die gewünschten Angaben schon in den entsprechenden Dateien (korrekt) eingetragen sind. Am wichtigsten ist dabei die Datei /etc/initramfs-tools/conf.d/resume. Wenn nicht, dann die Angaben in die entsprechenden Dateien schreiben bzw. korrigieren.

6. initrd aktualisieren:
   

   sudo update-initramfs -u 

7. /boot/grub/menu.lst aktualisieren:
   

   sudo /sbin/update-grub 

8. System neu starten und STD testen.

9. Wenn Fehler auftreten, dann bei Fehlersuche weitermachen.

Der folgende Einzeiler fasst die Schritte 1. bis 4. zusammen:

ls -l /dev/disk/by-uuid/ | grep $(cat /proc/swaps | tail -$(($(cat /proc/swaps | wc -l)-1)) | awk '{print $1}' | awk -F/ '{print $3}') | awk -F' ' '{print $8}' 

STD auf separater Partition¶

Salopp gesagt: In diesem Fall ist man (sehr) fortgeschrittener Anwender, man kennt sich gut aus und man weiß i.d.R, was man hat und was man will. Folgendes ist zu tun (analog zu weiter oben):

1. Ggf. zuerst eine SUSPEND-Partition erstellen

2. Partitionsname aus der Ausgabe von
   

   sudo fdisk -l 

   
   ablesen

3. Partitionsname bzw. UUID-Identifier der Partition aus /etc/fstab ablesen

4. UUID-Identifier aus der Ausgabe von
   

   ls -l /dev/disk/by-uuid 

   
   ablesen (Vergleich mit Ausgabe von sudo fdisk –l)

5. Überprüfen, ob die gewünschten Angaben schon in den entsprechenden Dateien (korrekt) eingetragen sind. Am wichtigsten ist dabei die Datei /etc/initramfs-tools/conf.d/resume. Wenn nicht, dann die Angaben in die entsprechenden Dateien schreiben bzw. korrigieren.

6. initrd aktualisieren:
   

   sudo update-initramfs –u 

7. /boot/grub/menu.lst aktualisieren:
   

   sudo /sbin/update-grub 

8. System neu starten und STD testen.

9. Wenn Fehler auftreten, dann bei Fehlersuche weitermachen.

Sonderfälle¶

Auf einem System können mehrere SWAP-Partitionen existieren, so zum Beispiel wenn mehrere Linux-Installationen mit jeweils separater SWAP-Partition vorhanden sind. Nicht jede SWAP-Partition muss im Einsatz (aktiviert) sein. Das ist zum Beispiel dann der Fall, wenn der Eintrag zu SWAP-Partition(en) in fstab nicht korrekt ist, oder wenn aus Umbau-Maßnahmen mehrere SWAP-Partitionen vorhanden sind, aber nur eine verwendet wird.

Die UUID-Bezeichner für alle aktiven SWAP-Partitionen, die tatsächlich im Einsatz (aktiv) sind, kann man so herausfinden:

cat /proc/swaps # zeigt die aktiven SWAP-Partitionen an
ls -l /dev/disk/by-uuid/ # zeigt die Zuordnung Partitionen <=> UUID-Identifier 

Man sucht sich nun die "richtige" SWAP-Partition heraus und verwendet diese. Außerdem hat man nun womöglich einen ganz anderen Fehler entdeckt, den es zu beheben gilt.

Log-Datei /var/log/pm-suspend.log¶

Die Log-Datei für pm-utils ist /var/log/pm-suspend.log. Diese Datei wird bei jeder Einleitung eines SUSPEND-Vorgangs geleert und neu beschrieben. In dieser Datei wird sowohl der SUSPEND-, als auch der RESUME-Vorgang protokolliert. Hat man nach einem missglückten SUSPEND-RESUME-Vorgang Veränderungen vorgenommen, so kann man eine Kopie der Log-Datei /var/log/pm-suspend.log speichern um sie mit ihrem Nachfolger zu vergleichen.

Aussagekräftiger wird diese Datei, wenn man den SUSPEND auf der Konsole startet und davor der Variable $PM_DEBUG den Wert true zuweist:

export PM_DEBUG=true

SUSPEND und/oder RESUME funktioniert nicht¶

Das kann viele Ursachen haben. Einige davon sind oben angesprochen. Für die einzelnen Ursachen sind die Maßnahmen in den entsprechenden, nachfolgenden Unterkapiteln beschrieben. An dieser Stelle sind noch weitere Fehlerursachen beschrieben, die in manchen Fällen SUSPEND und RESUME verhindern:

Option          "NvAGP"       "1"

Module vor SUSPEND entladen, nach RESUME wieder laden¶

In der Regel ist es ausreichend, Kernelmodule für die problematiche Hardware automatisch vor SUSPEND entladen und während RESUME neu laden zu lassen. Die Module, die häufig Ärger bereiten, sind die Module für:

• WLAN-Karten und USB-WLAN-Sticks: *802*, ndiswrapper, ...

• LAN-Karten: forcedeth, *8139*, ...

• USB- und Firewire-Module: ehci-hcd, uhci-hcd, *usb*, *1394, ...

• Bluetooth- und TV-Karten: ivtv, bttv, btusb, ...

Mit dem folgenden Einzeiler kann man sich die "üblichen Verdächtigen" anzeigen lassen:

lsmod | grep -iE 'usb|1394|hci|ndiswr|forced|8139|hid|802'

Diese Liste erhebt allerdings keinen Anspruch auf Vollständigkeit.

Ab Intrepid verwendet man die (vorhandene) Datei /etc/pm/config.d/00sleep_module, in früheren Ubuntu-Versionen erstellt man eine Datei unload_modules (ein anderer beliebiger Name ist auch richtig) im Verzeichnis /etc/pm/config.d/. Hat man herausgefunden, dass die Module ehci-hcd uhci-hcd usbcore forcedeth SUSPEND (und/oder RESUME verhindern), so fügt man die folgenden Zeilen in diese Datei ein:

# USB-Kernelmodule und forcedeth (Netzwerkkarte) machen Aerger bei SUSPEND & RESUME mit pm-utils
# daher sollen sie automatisch ent- und geladen werden
SUSPEND_MODULES="$SUSPEND_MODULES ehci-hcd uhci-hcd usbcore forcedeth" 

Durch die o.g. Zuweisung werden diejenigen Module, die bereits an einer anderen Stelle in der Variable SUSPEND_MODULES hinterlegt wurden, nicht überschrieben. Nachdem diese Datei erstellt wurde, testet man SUSPEND und RESUME. In der Tabelle unten sind die Module aufgelistet, die in der jeweiligen Ubuntu-Version bei einem oder mehreren Benutzern SUSPEND (und RESUME) verhinderten.

Diese Liste kann als "Start-Liste" benutzt werden. Wenn SUSPEND und RESUME klappen, dann kann man ein Modul nach dem anderen aus der o.g. Liste entfernen, und SUSPEND und RESUME wieder testen, bis man den/die Übeltäter gefunden hat. Es schadet natürlich nicht, wenn man zu Testzwecken alle Module (für alle Versionen) in seine eigene SUSPEND_MODULES-Liste packt. Oder man lässt diese Liste so wie sie ist, da der Zeitgewinn nur minimal ist, wenn man ein oder zwei Module weniger als erforderlich entladen und neu laden läst. Selbstverständlich erhebt diese Liste keinen Anspruch auf Vollständigkeit.

Falls jemand einen oder mehrere weitere Module entdeckt, die entladen und neu geladen werden müssen, damit SUSPEND und RESUME klappen, bitte die Liste für die entsprechende Version vervollständigen! Dabei sollen nur diejenigen Module eingetragen werden, bei denen es sichergestellt ist, dass sie SUSPEND und RESUME tatsächlich verhindern.

Bei Lucid auf äteren ASUS-Boards mit PS/2-Anschlüssen ist es offenbar erforerlich, im BIOS die Funktion "USB Legacy Support" abzuschalten. Dies ist natürlich nur sinnvoll, falls man eine PS/2-Tastatur benutzt.

Weitere Details dazu findet man auf Launchpad und im Forum und speziell zu Lucid hier.

Eine gute Anleitung auf englisch, um solche Module, die Ärger verursachen, ist hier zu finden: "resume-trace" debugging procedure for finding buggy drivers.

Dienste vor SUSPEND stoppen, nach RESUME wieder starten¶

Mit den Diensten, die nach dem RESUME nicht funktionieren, sollte man analog zu den Kernelmodulen verfahren:

• Zuerst herausfinden, welcher Dienst gestoppt und wieder gestartet werden muss.

• Einen Hook unter Verwendung des Beispiel-Hooks erstellen.

ACPI abgeschaltet¶

Aus mehreren Gründen kann es vorkommen, dass entweder alle oder nur bestimmte ACPI-Funktionalitäten abgeschaltet sind. Dies kann entweder im BIOS oder über Kernelparameter erreicht werden. Daher sollten unter ^[4] die BIOS-Einstellungen und ACPI-Kernelparameter kontrolliert werden.

Grafikkartentreiber und Desktop-Effekte¶

Nvidia
Laut Grafikkarten/Nvidia/Suspend ist es erforderlich, in der Datei /etc/X11/xorg.conf im Abschnitt "Device" die NvAGP-Option zu ergänzen:

1
2
3
4

Section "Device"
        Driver          "nvidia"
        Option          "NvAGP"       "1"
EndSection

Außerdem wurde mehrmals festgestellt, dass der Nvidia-Treiber in der Version 180 SUSPEND verhindert. In diesem Fall sollte der treiber durch einen älteren ersetzt werden!

ATI
Oft wird berichtet, dass SUSPEND funktioniert, wenn radeon statt fglrx verwendet wird.

Desktop-Effekte
Manchmal wird berichtet, dass SUSPEND funktioniert, nachdem Desktop-Effekte abgeschaltet werden.

SUSPEND und RESUME stufenweise testen¶

Zur Fehlersuche ist es ratsam, stufenweise vorzugehen. Das bedeutet, dass man zuerst den XServer beendet und SUSPEND von einer Konsole aus startet. Wenn das funktioniert, dann startet man SUSPEND aus X heraus.

SUSPEND und RESUME ohne X (aus RUNLEVEL 1) testen:

• von GNOME/KDE/… abmelden

• mit Strg + Alt + F1 zur Konsole wechseln

• anmelden

• sudo init 1 

• mit
  

  /usr/sbin/pm-suspend 

  
  bzw.
  

  /usr/sbin/pm-hibernate 

  
  SUSPEND starten

• Anschließend RESUME einleiten, indem der Rechner wieder eingeschaltet wird.

Man kann das auch testen, indem man nicht (mit sudo init 1) in den RUNLEVEL 1 wechselt, sondern direkt nach der Anmeldung in der Konsole mit sudo /usr/sbin/pm-suspend bzw. sudo /usr/sbin/pm-hibernate den SUSPEND-Vorgang startet.

STD wird ausgeführt, kein RESUME¶

Der Rechner wird in den Schlaf versetzt. Nach dem Wiedereinschalten startet das System "normal".

Meistens liegt es daran, dass die Angabe zur "SUSPEND & RESUME-Partition" an einer oder mehreren der folgenden Stellen falsch ist:

• /etc/initramfs-tools/conf.d/resume (und damit auch in initrd)

• /etc/uswsusp.conf

• /boot/grub/menu.lst

Eventuell sind die Angaben sogar korrekt, nur das abschließende sudo update-initramfs -u wurde vergessen. Weiter oben unter Suspend_To_Disk ist beschrieben, wie man feststellen kann, welche Partition die richtige ist, und wie man die Angaben dazu aktualisiert.

Nach RESUME kein Ton (Intel HDA)¶

Intel HDA ist eine Definition von Intel für integrierte Soundlösungen. Auf unterschiedlichen Mainboards kommen unterschiedliche Chipsätze zum Einsatz. Das bedeutet, das der "Intel HDA"-Treiber eine ganze Gruppe von Soundchips unterstützt. Derzeit funktioniert diese Gruppe von Soundchips nicht richtig mit dem Kernel 2.6.24-15/16. Die Bugs sind in Launchpad immernoch offen, und eine Menge Anwender sind davon betroffen. Meistens funktionieren die Chips selber ohne Probleme mit diesem Kernel und Hardy, aber nur bis zum SUSPEND. Sie werden beim RESUME nicht richtig aufgeweckt, aber vom System als wieder aktiviert erkannt. Die lspci-Ausgabe zeigt die Soundchips als aktiv an, und die Systemprotokolle zeigen nichts ungewöhnliches.

Lösung für dieses Problem:

Mit

aplay -l 

den Chipsatz herausfinden! Das Ergebnis könnte so aussehen:

aplay -l 
**** Liste von PLAYBACK Geräten ****
Karte 0: Intel [HDA Intel], Gerät 0: ALC268 Analog [ALC268 Analog]
  Untergeordnete Geräte: 0/1
  Untergeordnetes Gerät '0: subdevice #0

Im Beispiel oben ist ALC268 der gesuchte Begriff.
Mit

zless /usr/share/doc/alsa-base/driver/ALSA-Configuration.txt.gz 

nach dem Chipsatz (im Beispiel oben ALC268) suchen! Das Ergebnis könnte so aussehen:

ALC268
          3stack        3-stack model
          toshiba       Toshiba A205
          acer          Acer laptops
          dell          Dell OEM laptops (Vostro 1200)
          zepto         Zepto laptops
          test          for testing/debugging purpose, almost all controls can
                        adjusted.  Appearing only when compiled with
                        $CONFIG_SND_DEBUG=y
          auto          auto-config reading BIOS (default)

Auf Acer-Notebooks wäre acer der gesuchte Begriff.
In den Dateien /etc/modprobe.d/snd-hda-intel.modprobe und /etc/modprobe.d/alsa-base muss folgende Zeile eingetragen werden:

options snd-hda-intel model=acer

Im Forum wird oft die Anweisung gegeben, in der Datei /etc/default/acpi-support noch folgende Änderung vorzunehmen:

# Add services to this list to stop them before suspend and restart them in
# the resume process.
STOP_SERVICES="alsa"

Dies dürfte sich allerdings auf SUSPEND & RESUME mit pm-utils nicht auswirken, da pm-utils die Dateien aus dem Paket acpi-support nicht verwendet. Möchte man aber sowohl pm-utils als auch acpi-support für SUSPEND & RESUME nutzen, so sollte die Änderung in /etc/default/acpi-support vorgenommen werden.

Anschließend muss man die Dienste neu starten, ggf. Module entladen und neu laden. Wenn´s nicht klappt, einen Neustart durchführen.

Weitere Informationen zu diesem Problem können dem Thread nach-standby-kein-ton-mehr im uu.de-Forum entnommen werden.

Debug-Modus verwenden¶

Den Debug-Modus schaltet man auf diese Weise ein:

sudo su -  # startet eine root Shell
echo 1 > /sys/power/pm_trace # aktiviert Debug Modus 

Die gezielte Suche nach den Modulen oder Geräten, die Ärger bei SUSPEND und RESUME verursachen, ist nach diesem Schema durchzuführen:

• ggf. vom Desktop (KDE, GNOME, ...) abmelden

• mit Strg + Alt + F1 zur Konsole wechseln

• anmelden

• sudo su - 

• echo 1 > /sys/power/pm_trace 

• /usr/sbin/pm-suspend 

  
  oder
  

  /usr/sbin/pm-hibernate 

• Das System geht in SUSPEND über.

• Wenn "Ruhe" eingekehrt ist, dann RESUME einleiten durch Drücken der Power-Taste.

• RESUME startet

• Wenn der RESUME-Vorgang "anscheinend durchgelaufen ist", dann den Rechner ausschalten und neu starten (booten). Zwischen dem Erreichen der "Ruhe" (zwei Schritte vor diesem hier) und dem aktuellen Zeitpunkt (Neustart) darf nicht mehr Zeit als 2 bis 3 Minuten vergehen! Da ins RTC geschrieben wird, werden beim nächsten Start des Systems höchstwahrscheinlich Dateisystemcheck durchgeführt. Nicht verunsichern lassen - einfach abwarten!

• Sobald das System gestartet ist, mit Strg + Alt + F1 zur Konsole wechseln

• anmelden

• cd /tmp 

• dmesg > dmesg.txt 

• grep "hash matches" dmesg.txt > dmesg_hash_matches.txt 

• Die Dateien /tmp/dmesg.txt und /tmp/dmesg_hash_matches.txt können nun bei der Fehlersuche verwendet und im Forum gepostet werden.

Ist die Datei /tmp/dmesg_hash_matches.txt nicht leer, so hat man entweder direkt den Modulnamen oder aber zumindest einen Hinweis auf das entsprechende Gerät. Der Modulname sollte nun in die Liste der Module eingefügt werden, die vor SUSPEND entladen und während RESUME neu geladen werden sollten. Details dazu weiter oben.

Eigene Hooks erstellen¶

Für den sehr unwahrscheinlichen Fall, dass man selbst Hooks erstellen muss, hier das Beispiel /usr/lib/pm-utils/sleep.d/05led. Daraus ist ersichtlich, dass beim Betreten von STR und STD echo "7 blink" >/proc/acpi/ibm/led, beim Wiedererwachen hingegen echo "7 off" >/proc/acpi/ibm/led aufgerufen wird.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

#!/bin/bash

[ -f /proc/acpi/ibm/led ] || exit 0

case "$1" in
	hibernate|suspend)
		{ echo "7 blink" >/proc/acpi/ibm/led ; } 2>/dev/null
		;;
	thaw|resume) 
		{ echo "7 off" >/proc/acpi/ibm/led ; } 2>/dev/null
		;;
	*)
		;;
esac

exit $?