Installation¶

pm-utils ist in der Standardinstallation immer enthalten. Bei einer Minimalinstallation oder anderen Ubuntu-Varianten muss ggf. das folgende Paket installiert werden ^[1]:

• pm-utils

Befehl zum Installieren der Pakete:

sudo apt-get install pm-utils 

Oder mit apturl installieren, Link: apt://pm-utils

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, dass i.d.R. vorinstalliert ist.

• 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¶

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

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

   sudo fdisk -l | grep Swap | awk '{print $1}' 

   ablesen

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

   grep swap /etc/fstab 

3. UUID 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 (siehe oben). Am wichtigsten ist dabei die Datei /etc/initramfs-tools/conf.d/resume. Wenn nicht, dann die Angaben in die entsprechenden Dateien schreiben bzw. korrigieren (und ggf. die GRUB-Konfiguration aktuallisieren).

6. initrd aktualisieren:

   sudo update-initramfs -u 

7. System neu starten und STD testen.

8. Wenn Fehler auftreten, dann bei Fehlersuche weitermachen.

Der folgende Einzeiler fasst die Schritte 1. bis 4. zusammen und liefert Partitions-Namen ("/dev/xxxy") und UUID, wenn alles in Ordnung ist (andernfalls manuell überprüfen):

dev=$(tail -n 1 /proc/swaps | awk '{print $1}'); uuid=$(ls -l /dev/disk/by-uuid/ | grep $(awk -F/ '{print $3}' <<<"$dev") 2> /dev/null | awk -F' ' '{print $9}'); echo "Partition: $dev; UUID: $uuid" 

Der gleiche Einzeiler ohne den awk:

dev=$(tail -n 1 /proc/swaps | cut -d" " -f1 | cut -d/ -f3); uuid=$(ls -l /dev/disk/by-uuid/ | grep $dev | cut -d" " -f9); echo "Partition: /dev/${dev}; UUID: $uuid" 

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 (siehe oben). Am wichtigsten ist dabei die Datei /etc/initramfs-tools/conf.d/resume. Wenn nicht, dann die Angaben in die entsprechenden Dateien schreiben bzw. korrigieren (und ggf. die GRUB-Konfiguration aktuallisieren).

6. initrd aktualisieren:

   sudo update-initramfs –u 

7. System neu starten und STD testen.

8. 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 oder auch wenn zRam verwendet wird. Nicht jede SWAP-Partition muss zur Verwendung 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. Vom aktuellen Ubuntu 16.04 werden im Ggs. dazu auch nicht in der fstab eingetragene SWAP-Partitionen verwendet.

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. Dabei ist es höchstwahrscheinlich auch nötig, diese wie oben beschrieben als Kernel-Bootparameter in der GRUB-Konfiguration anzugeben. 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 problematische Hardware automatisch vor SUSPEND entladen und während RESUME neu laden zu lassen. Die Module, die häufiger Ärger bereiten können, 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 '802|ndiswr|forced|8139|hci|usb|1394|hid|..tv' 

Diese Liste erhebt allerdings keinen Anspruch auf Vollständigkeit.

Die benötigte Datei /etc/pm/config.d/00sleep_module muss oft zunächst noch erstellt und anschließend ausführbar gemacht werden:

sudo touch /etc/pm/config.d/00sleep_module               # Datei erstellen
sudo chmod +x /etc/pm/config.d/00sleep_module            # ausführbar machen 

Hat man herausgefunden, dass die Module ehci-hcd uhci-hcd usbcore forcedeth SUSPEND (und/oder RESUME verhindern), bearbeitet man die Datei mit einem Texteditor ^[3] und fügt folgende Zeilen 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 einer eigenen SUSPEND_MODULES-Liste aufführt. Dies erreicht man, indem man die folgende Ausgabe:

cat /proc/modules | cut -d " " -f1 | xargs 

in die oben genannte Datei kopiert. 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ässt. 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 Ubuntu 10.04 auf älteren ASUS-Boards mit PS/2-Anschlüssen war es beispielsweise offenbar erforderlich, im BIOS die Funktion USB Legacy Support abzuschalten. Dies war natürlich nur sinnvoll, falls man eine PS/2-Tastatur benutzt. Weitere Details dazu findet man auf Launchpad und im Forum und speziell zu Ubuntu 10.04 hier.

Eine gute Anleitung, um solche Module aufzuspüren, 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 (siehe unten) erstellen

ACPI abgeschaltet¶

Aus mehreren Gründen kann es vorkommen, dass entweder alle oder nur bestimmte ACPI-Funktionen 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¶

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:

1. Von Desktop abmelden

2. Mit Strg + Alt + F1 zu einer virtuellen Konsole wechseln

3. Anmelden

4. sudo init 1 

5. SUSPEND oder HIBERNATE starten:

   /usr/sbin/pm-suspend 

   oder

   /usr/sbin/pm-hibernate 

6. 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 immer noch offen, und viele Anwender sind davon betroffen. Meistens funktionieren die Chips selber ohne Probleme mit diesem Kernel, 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 dem folgenden Befehl den Chipsatz herausfinden.

aplay -l 

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 Forum entnommen werden.

Nach RESUME kein Netzwerk¶

Als Erstes soll man herausfinden, welche Kernel-Module für die vorhandenen Netzwerk-Schnittstellen zuständig sind. Dies kann man mit dem folgenden Befehl erreichen:

sudo lshw -C network 

Die Ausgabe soll ungefähr so aussehen:

  *-network               
       Beschreibung: Wireless interface
       (...)
  *-network               
       Beschreibung: Ethernet interface
       Produkt: VT6102 [Rhine-II]
       Hersteller: VIA Technologies, Inc.
       (...)
       Konfiguration: autonegotiation=on broadcast=yes driver=via-rhine driverversion=1.5.1 duplex=full ip=192.168.0.62 latency=64 link=yes maxlatency=8 mingnt=3 multicast=yes port=MII speed=100Mbit/s
       Ressourcen: irq:23 ioport:4800(Größe=256) memory:d9300400-d93004ff

Das Kernelmodul sieht man in der Zeile "Konfiguration" (in diesem Fall driver=via-rhine). Man soll noch herausfinden, wie das entsprechende Modul tatsächlich heißt, in diesem Fall z.B. so:

$ lsmod | grep rhine
via_rhine              27653  0 
mii                    13654  1 via_rhine

Man sieht, dass in diesem Fall die Namen von Treiber und Modul sich leicht unterscheiden. Den Modulname trägt man in die oben beschriebene Datei /etc/pm/config.d/00sleep_module ein:

SUSPEND_MODULES="$SUSPEND_MODULES via_rhine"

Wichtig dabei ist, dass der Network-Manager vor SUSPEND gestoppt und nach RESUME wieder gestartet wird. Dies wird im Skript /etc/pm/sleep.d/50_network_suspend.sh implementiert:

#!/bin/sh
# /etc/pm/sleep.d/50_network_suspend.sh

case "${1}" in
    hibernate|suspend)
	service network-manager stop ;;
    resume|thaw)
        service network-manager start ;;
esac

Neustart bei Hibernate¶

Manche Geräte starten sofort neu, oder reagieren auf jede Taste, nachdem sie in den Ruhezustand (S4) geschaltet wurden. Dieses Problem kann gelöst werden, indem man die pm-utils anweist, stattdessen ein Shutdown-Signal zu verwenden:

1. Datei /usr/lib/pm-utils/defaults öffnen

2. Die Zeile

   # HIBERNATE_MODE="platform"

   einkommentieren.

3. Anstelle von platform hier shutdown eintragen.

4. Datei als "/etc/pm/config.d/defaults" speichern.

Auch ein reboot ist möglich, falls gewünscht.

Debug-Modus verwenden¶

Den Debug-Modus schaltet man auf diese Weise ein:

echo 1 | sudo tee /sys/power/pm_trace 

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

1. Ggf. vom Desktop (KDE, GNOME, ...) abmelden

2. mit Strg + Alt + F1 in eine virtuelle Konsole wechseln

3. Anmelden

4. Debug-Modus aktivieren:

   echo 1 | sudo tee /sys/power/pm_trace 

5. SUSPEND oder HIBERNATE starten:

   /usr/sbin/pm-suspend 

   oder

   /usr/sbin/pm-hibernate 

6. Das System geht in SUSPEND über.

7. Wenn der Ruhezustand eingekehrt ist, dann RESUME einleiten durch Drücken der Power-Taste.

8. RESUME startet

Wenn der RESUME-Vorgang durchgelaufen ist, dann den Rechner ausschalten und neu starten (booten). Zwischen dem Erreichen des Ruhezustands und dem aktuellen Zeitpunkt (Neustart) darf nicht mehr Zeit als 2 bis 3 Minuten vergehen! Da in die Hardware-Uhr (real-time clock, RTC) geschrieben wird, werden beim nächsten Start des Systems höchstwahrscheinlich Dateisystemchecks durchgeführt. Nicht verunsichern lassen - einfach abwarten!

1. Sobald das System gestartet ist, mit Strg + Alt + F1 zu einer virtuelle Konsole wechseln

2. Anmelden

3. cd /tmp
   dmesg > dmesg.txt
   grep "hash matches" dmesg.txt > dmesg_hash_matches.txt 

4. 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. Nach dem Erstellen muss der Hook noch ausführbar gemacht werden.

 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 $?

Bildschirm nach 5-10 min wieder schwarz¶

Nach Bereitschaft oder Ruhezustand kann die Bereitschaftszeit zurückgesetzt sein, etwa bei Xubuntu oder Lubuntu 14.04. Das führt dazu, dass die Zeit bis zum schwarzen Bildschirm, je nach Voreinstellung, zu kurz gesetzt ist. Mögliche Lösungen werden in Bildschirmschoner (Abschnitt „Bildschirm-nach-5-10-min-schwarz“) vorgestellt.

STR wird nach wenigen Sekunden unterbrochen¶

Der Rechner startet den Bereitschaftsmodus, wird aber nach einer, bzw. nach wenigen Sekunden "aus dem Schlaf gerissen" und läuft normal weiter. Dies passiert immer dann, wenn ein Gerät ein Aufwachsignal sendet. Nun kann man, wie oben beschrieben, die entsprechenden Module vor dem Bereitschaftsmodus entladen und danach wieder laden, oder man entzieht dem entsprechenden Gerät die Erlaubnis, den Rechner aus dem Bereitschaftsmodus zu wecken.

Zuerst werden alle Geräte aufgelistet, welche ein Aufwachsignal senden können:

nl /proc/acpi/wakeup 

     1	Device	S-state	  Status   Sysfs node
     2	SMB0	  S4	*disabled  pci:0000:00:03.2
     3	NMAC	  S5	*disabled
     4	PBB0	  S4	*disabled  pci:0000:00:09.0
     5	HDAC	  S4	*disabled  pci:0000:00:08.0
     6	XVR0	  S4	*disabled
     7	P0P5	  S4	*disabled
     8	P0P6	  S4	*disabled
     9	P0P7	  S4	*disabled  pci:0000:00:16.0
    10	P0P8	  S4	*disabled
    11	P0P9	  S4	*disabled  pci:0000:00:18.0
    12	XVR1	  S4	*disabled
    13	USB0	  S3	*enabled   pci:0000:00:04.0
    14	USB2	  S3	*enabled   pci:0000:00:04.1
    15	US15	  S3	*enabled   pci:0000:00:06.0
    16	US12	  S3	*enabled   pci:0000:00:06.1
    17	SLPB	  S4	*enabled   platform:PNP0C0E:00

Am Beispiel ist zu erkennen, dass Zeile 13-17 Aufwachsignale senden dürfen (*enabled) während Geräte von Zeile 1 bis 12 keine Aufwachsignale senden dürfen (*disabled).

Um jetzt herauszufinden welches Gerät den Bereitschaftsmodus unterbricht, deaktiviert man ein Gerät nach dem anderen und testet jeweils danach den Bereitschaftsmodus. Hierzu werden alle Geräte nacheinander auf *disabled gesetzt bis das "schuldige Gerät" gefunden wurde.

In den permanenten root-Modus wechseln:

sudo -i 

Nun deaktiviert man das erste Gerät

echo USB0 > /proc/acpi/wakeup 

und kontrolliert das Ergebnis mit:

nl /proc/acpi/wakeup 

     1	Device	S-state	  Status   Sysfs node
     2	SMB0	  S4	*disabled  pci:0000:00:03.2
     3	NMAC	  S5	*disabled
     4	PBB0	  S4	*disabled  pci:0000:00:09.0
     5	HDAC	  S4	*disabled  pci:0000:00:08.0
     6	XVR0	  S4	*disabled
     7	P0P5	  S4	*disabled
     8	P0P6	  S4	*disabled
     9	P0P7	  S4	*disabled  pci:0000:00:16.0
    10	P0P8	  S4	*disabled
    11	P0P9	  S4	*disabled  pci:0000:00:18.0
    12	XVR1	  S4	*disabled
    13	USB0	  S3	*disabled   pci:0000:00:04.0
    14	USB2	  S3	*enabled   pci:0000:00:04.1
    15	US15	  S3	*enabled   pci:0000:00:06.0
    16	US12	  S3	*enabled   pci:0000:00:06.1
    17	SLPB	  S4	*enabled   platform:PNP0C0E:00

Nun muss der Bereitschaftsmodus getestet werden. Ist der Bereitschaftsmodus immer noch nicht permanent, so deaktivert man testweise das nächste Gerät. Sobald das entsprechende Gerät gefunden wurde, ergänzt man einfach die Datei /etc/rc.local um folgenden Zeile: (USB0 ist hier nur das Bespiel, bitte entsprechendes Geräte (DEVICE) eintragen):

echo USB0 > /proc/acpi/wakeup 

Zum Schluss muss dann noch die Root-Shell verlassen werden:

exit