[[Vorlage(Archiviert, )]] [[Vorlage(Fortgeschritten)]] {{{#!vorlage Wissen [:Pakete_installieren: Installation von Programmen] [:Terminal: Ein Terminal öffnen] [:Editor: Einen Texteditor öffnen] [:Archiv/Energiesparmodi mit ACPI:] [:Archiv/uswsusp:Einsatz von uswsusp] [:sudo:Root-Rechte] }}} [[Inhaltsverzeichnis(2)]] '''pm-utils''' steht für '''P'''ower'''M'''anagement'''-Utils'''. Dieses Paket ist bis Ubuntu 14.10 Standard für den Wechsel in unterschiedliche Energiesparmodi. {{{#!vorlage Hinweis Seit [:15.04:Ubuntu 15.04] wird [:systemd:] für den Wechsel der Energiesparmodi verwendet. Dadurch sind viele Funktionen von pm-utils nicht mehr nutzbar. }}} Das Paket '''pm-utils''' beinhaltet (hauptsächlich) Skripte, die SUSPEND- und RESUME-Vorgänge (siehe auch [:Archiv/Energiesparmodi mit ACPI:]) ausführen. Dabei können die pm-utils-Skripte direkt (in einer Shell) oder indirekt (vom gnome-power-manager unter GNOME, bzw. von kpowersave / powerdevil unter KDE) im Auftrag von HAL aufgerufen werden [4]. Die pm-utils-Skripte greifen automatisch auf [:Archiv/uswsusp:] zurück, sofern das Paket '''uswsusp''' [5] installiert ist und nicht explizit auf Kernel-Methoden zurückgegriffen werden sollte. Die PowerManagement-Funktionen des Pakets pm-utils sollten ohne weiteres Zutun des Benutzers funktionieren. Ist dies nicht der Fall, so liegt es sehr häufig an den fehlerhaften Treibern oder an einer fehlerhaften Konfiguration des Systems. STR (=Suspend-to-RAM) und STD (=Suspend-to-Disc) funktionieren auf einem frisch installierten Ubuntu-System und auf Systemen, in denen nicht die aktuellste Hardware verbaut ist, häufiger als auf Systemen, die die neueste bzw. spezielle Hardware beinhalten oder im Laufe der Zeit Änderungen erfahren haben. Beispiele: * auf derselben Hardware sind mehrere Linux-Installationen (mit mehreren SWAP-Partitionen) vorhanden, wobei nicht alle SWAP-Partitionen in allen Linux-Installationen aktiviert sein müssen * die SWAP-Partition(en) wurden vergrößert oder verkleinert * Arbeitsspeicher wurde hinzugefügt oder ausgebaut Durch solche Veränderungen am System kann es passieren, dass die zunächst ermittelten Werte über die SWAP-Partition, deren Größe usw. nicht mehr korrekt sind. Damit funktioniert STR oder/und STD dann nicht mehr. Andererseits funktionieren STR und/oder STD auf anderen Systemen von Anfang an nicht, weil z.B. spezielle Hardware, die Ärger verursacht, verbaut ist. Die Gründe und die Fehlerursachen für nicht funktionierende Energiesparmodi sind sehr vielfältig. Dieser Artikel sollte helfen, diese Fehlerursachen zu finden und zu beheben. Dazu muss ein wenig ausgeholt werden. Zuerst werden das Paket pm-utils, dessen Bestandteile (die pm-utils-Hooks) und der grundsätzliche Ablauf von SUSPEND und RESUME mit pm-utils erläutert. Im darauf folgenden Abschnitt ist erklärt, wie man herausfinden kann, welche Energiesparmodi auf dem eigenen System möglich sind. Anschließend wird erklärt, wie man STR und/oder STD einrichtet. Das letzte Kapitel behandelt Fehlersuche, Aktivierung des DEBUG-Modus u.ä. = Das Paket pm-utils = == Installation == pm-utils ist in der Standardinstallation immer enthalten. Bei einer Minimalinstallation oder anderen Ubuntu-Varianten muss ggf. das folgende Paket installiert werden [1]: {{{#!vorlage Paketinstallation pm-utils }}} Die Dokumentation findet man unter '''/usr/share/doc/pm-utils'''. {{{#!vorlage Warnung Das Paket '''pm-utils''' sollte nie entfernt werden, da sonst Energiesparfunktionen nicht mehr genutzt werden können! }}} 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. || '''Datei/Verzeichnis''' || '''Beschreibung/Inhalt''' || || '''/etc/pm/config.d/''' || Verzeichnis, in dem Konfigurationsdateien abgelegt werden können, mit denen dann die Standardeinstellungen aus '''/usr/lib/pm-utils/''' überschrieben werden. || || '''/etc/pm/power.d/''' || Das Verzeichnis für die eigenen Hooks für Energiesparmodi , in denen kein SUSPEND gemacht wird. || || '''/etc/pm/sleep.d''' || Das Verzeichnis für die eigenen Hooks für Suspend-Energiesparmodi. || || '''/usr/bin/pm-is-supported''' || Programm, mit dem geprüft werden kann, welche SUSPEND-Modi erreichbar sind || || '''/usr/lib/pm-utils/defaults''' || Standard-Einstellungen für pm-utils || || '''/usr/lib/pm-utils/functions''' || Funktionen, die von pm-utils-Skripten verwendet werden || || '''/usr/lib/pm-utils/bin/pm-action''' || Das Skript, dass die Arbeit verrichtet || || '''/usr/lib/pm-utils/power.d/''' || Das Verzeichnis mit den Hooks für Energiesparmodi , in denen kein SUSPEND gemacht wird. Zum Beispiel, anacron stoppen, wenn Notebook nicht am Netz ist, sondern vom Akku mit Spannung versorgt wird. || || '''/usr/lib/pm-utils/sleep.d/''' || Das Verzeichnis mit den Hooks für Suspend-Energiesparmodi. || || ''' zusätzlich im Paket enthalten''' || || '''/etc/pm/config.d/00sleep_module''' || Datei, in die Benutzer Module eintragen sollten, die entladen und geladen werden sollen|| || '''/usr/lib/pm-utils/module.d/''' || In diesem Verzeichnis existieren Dateien '''kernel''', '''tuxonice''', '''uswsusp''', mit den Definitionen der Funktionen, die bei der entsprechenden SUSPEND & RESUME-Methode angewendet werden. Die Variable ``$SLEEP_MODULE`` definiert, welche der SUSPEND & RESUME-Methoden ``kernel, tuxonice, uswsusp`` gilt. Voreinstellung ist ``kernel``. || || '''/usr/lib/pm-utils/pm-functions''' || '''pm-functions''' enthält nur die Funktionalitäten für pm-utils-"Frontends" ``pm-action``, ``pm-is-supported``, ``pm-powersave``. Die Datei '''functions''' wird auch von pm-utils-Hooks verwendet.|| == 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. {{{#!vorlage Hinweis Eigene Hooks werden in den Verzeichnissen '''/etc/pm/sleep.d''' bzw. '''/etc/pm/power.d''' gespeichert. Ein Beispiel-Hook ist weiter unten im Kapitel [#Eigene-Hooks-erstellen Eigene Hooks erstellen] enthalten. Mehr Informationen befinden sich in der Datei '''/usr/share/doc/pm-utils/HOWTO.hooks'''. }}} == SUSPEND- und RESUME mit pm-utils == === SUSPEND-Vorgänge mit pm-utils === * Beim Auswählen von ''"Bereitschaft"'' im GNOME-Abmeldemenü wird das Skript '''/usr/sbin/pm-suspend''' aufgerufen. * Beim Auswählen von ''"Ruhezustand"'' im GNOME-Abmeldemenü wird das Skript '''/usr/sbin/pm-hibernate''' aufgerufen. * Künftig wird womöglich eine dritte Schaltfläche vorhanden sein, mit der man in einen Hybrid-Energiesparmodus wechseln können wird, sogenannter SUSPEND-HYBRID-Modus. Dabei würde das Skript '''/usr/sbin/pm-suspend-hybrid''' aufgerufen werden. Diese Skripte können auch manuell ausgeführt werden, wobei alle Befehle/Skripte Root-Rechte[6] benötigen: * '''/usr/sbin/pm-suspend''' * '''/usr/sbin/pm-hibernate''' * '''/usr/sbin/pm-suspend-hybrid''' Dies sind allerdings "nur" symbolische Links auf das Skript '''/usr/lib/pm-utils/bin/pm-action''', das die eigentliche Arbeit verrichtet. Das Skript '''pm-action''' erkennt aus dem Aufruf (über die o.g. symbolischen Links) heraus, ob es von '''/usr/sbin/pm-suspend''' oder von '''/usr/sbin/pm-hibernate''' aufgerufen wurde. Daraufhin arbeitet das Skript die Hooks ab, indem sie in der entsprechenden Reihenfolge mit dem Parameter ``suspend`` bzw. ``hibernate`` aufgerufen werden. Anschließend wird der Rechner in den Schlaf geschickt. Bei STD wird das Image auf die SUSPEND-Partition geschrieben: * STD über Userspace: Wenn uswsusp installiert ist UND in keinem der aufgerufenen pm-utils-Skripte ``HIBERNATE_METHOD="kernel"`` gesetzt ist, dann gilt ``HIBERNATE_METHOD="autodetect"``. Das Skript pm-suspend findet '''/usr/sbin/s2disk''' bzw. '''/sbin/s2disk''' und setzt ``HIBERNATE_METHOD="userspace"``. Dabei wird die uswsusp-Konfiguration (standardmäßig) aus der Datei '''/etc/uswsusp.conf''' gelesen. * STD über Kernelspace: Wenn uswsusp __nicht__ installiert ist ODER in mindestens einem der augerufenen pm-utils-Skripte ``HIBERNATE_METHOD="kernel"`` gesetzt ist, dann wird auf Kernelspace zurückgegriffen, indem folgende Befehle (automatisch) abgesetzt werden: {{{#!vorlage Befehl echo -n "platform" > /sys/power/disk echo -n "disk" > /sys/power/state }}} === RESUME-Vorgang mit pm-utils === RESUME aus STR (S3) ist ein relativ einfacher Vorgang, in dem, vereinfacht gesagt, im Wesentlichen die Hardware-Komponenten mit Spannung versorgt werden, und der Rechner in den Arbeitszustand versetzt wird. Nachdem ein "Wake-up-Event" erkannt wurde, prüft das BIOS, ob RESUME_from_STR oder ein normaler Boot-Prozess gestartet werden soll. Wenn RESUME_from_STR erkannt wird, startet das BIOS den "Kernel-Wake-up-code". Die Hooks werden dabei, wie oben erwähnt, in der umgekehrten Reihenfolge abgearbeitet. Die entladenen Module werden ggf. wieder geladen, die angehaltenen Dienste ggf. wieder gestartet. Bei Notebooks wird noch die Hintergrundbeleuchtung eingeschaltet etc. RESUME aus STD (S4) ist ein etwas komplexerer Vorgang. Der Rechner bootet. Da das BIOS keinen Resume_from_STR erkannt hat, startet GRUB zuerst "ganz normal". Der Kernel liest die Boot-Parameter aus '''/boot/grub/menu.lst'''. Die initrd wird geladen, und an dieser Stelle kann (muss) der Kernel erkennen, dass der Rechner aus STD (S4) erwacht. Aus den Kernel-Parametern und/oder der initrd erfährt der Kernel, auf welcher Partition ein SUSPEND-Image vorhanden sein könnte. Wird nun kein SUSPEND-Image gefunden, so startet das System "normal weiter". Wird aber ein SUSPEND-Image gefunden, so wird dieses Image geladen und der RESUME_from_STD-Vorgang wird eingeleitet. Dabei wird der Inhalt des Images in den Arbeitsspeicher (zurück)geschrieben und die Hooks in der umgekehrten Reihenfolge abgearbeitet. Die entladenen Module werden wieder geladen, die angehaltenen Dienste wieder gestartet. Bei Notebooks wird noch die Hintergrundbeleuchtung eingeschaltet etc. = Vorbereitung, Entscheidung, Zieldefinition = Zuerst muss man herausfinden, welche Energiesparmodi erreicht werden können. Will man zum Beispiel STD erreichen, das System STD aber im aktuellen Zustand nicht unterstützt, so muss man zuerst das System in die Lage versetzen, STD erreichen zu können. Erst dann ist es sinnvoll, die Einrichtung von STD zu starten. == 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:{{{#!vorlage Befehl 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):{{{#!code bash #!/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. === Suspend_To_RAM === STR kann mit Hilfe von `pm-suspend` aus den pm-utils über den Kernelspace erreicht werden. Für die Alternative mit uswsusp im Userspace wird das dazu gehörige Programm `s2ram` genutzt. === Suspend_To_Disk === Will man STD einrichten, so muss man sich u.U. zuerst entscheiden, wohin das SUSPEND-Image (der Inhalt des Arbeitsspeichers) vor dem Einschlafen des Rechners geschrieben werden soll. Wenn vorhanden verwendet Ubuntu dafür standardmäßig die SWAP-Partition. Wenn ein Teil des Arbeitsspeichers im Betrieb schon dorthin ausgelagert ist, muss der erhalten bleiben, darf also nicht einfach durch das STD-Image überschrieben werden. Für STD muss die SWAP-Partition also immer groß genug sein, um den gesamten genutzten virtuellen Speicherbereich aufnehmen zu können. Hat man keine SWAP-Partition im System (z.B. weil man großen Arbeitsspeicher hat) und möchte man trotzdem STD nutzen, so kann eine separate SUSPEND-Partition erstellt werden. Z.Zt. ist keine Lösung bekannt, wie man das SUSPEND-Image alternativ wie z.B. bei Windows auch [:Swap/#Swap-als-Datei:in eine Datei schreiben] kann. Die Angabe über die Partition, auf die das SUSPEND-Image geschrieben wird, findet man an mehreren Stellen: * In der Datei '''/etc/initramfs-tools/conf.d/resume''' * Dabei kann sowohl der Partitionsname verwendet werden (``RESUME=/dev/sda2``), als auch der [:UUID:]-Identifier der Partition (z.B: `RESUME=UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx`). Der UUID-Identifier ist eindeutig fuer jedes Gerät. Laufwerksbuchstaben dagegen koennen leicht wechseln, beispielsweise bei Verwendung von Wechselplatten und USB-Sticks, aber auch bei Umhängen der Festplatte an einen anderen Controller oder "Um-Jumpern" einer IDE-Platte von Master zu Slave oder umgekehrt. Deswegen wird die Verwendung des UUID-Identifiers empfohlen, da weniger fehleranfällig. * Jedes Mal, wenn initrd neu erzeugt bzw. aktualisiert wird (zum Beispiel bei der Installation eines neuen Kernels), wird diese Datei gelesen und die Angabe in initrd geschrieben. * Diese Datei ist oft die Fehlerursache, weil diese Datei i.d.R. __nicht__ vom Benutzer aktualisiert wird, wenn die SWAP-Partition aufgrund eines Platten-Umbaus, -Einbaus oder -Ausbaus, oder im Rahmen einer Um-Partitionierung eine neue Bezeichnung erhält! * In der Datei '''/etc/uswsusp.conf''' * Diese Datei wird bei der Installation des Pakets '''uswsusp''' erstellt und mit Benutzer-Angaben befüllt, wenn die Konfiguration des Pakets uswsusp __nicht__ abgebrochen wird. Ansonsten steht irgendein Wert darin! Man kann diese Datei manuell anpassen oder "halb-automatsich" durch den Aufruf {{{#!vorlage Befehl sudo dpkg-reconfigure uswsusp }}} mit neuem Inhalt befüllen. Empfohlen wird hierzu die Lektüre der [:man:Manpage] zu uswsusp oder des Wiki-Artikels [:Archiv/uswsusp:] [5]. * Kernel-Bootparameter in der GRUB-Konfiguration * Häufig funktioniert das Resume nur, wenn auch in der GRUB-Konfigurationsdatei eingetragen ist, wo das Resume-Speicherabbild gespeichert ist. Diese Eintragung fehlt oft, so dass nach einem Hibernate der Rechner einen ganz normalen Neustart durchfuehrt. Auch wenn bei dieser Eintragung der Laufwerksbuchstabe/Partitionsnummer, beispielsweise `resume=/dev/sda2`, angegeben werden kann, wird empfohlen, die eindeutige Partitionskennung in der Form `resume=UUID=xxxxxxxxxxxxxx` zu verwenden (s.o.). Für [:GRUB_2/Konfiguration:GRUB 2] ergänzt man die Variable `GRUB_CMDLINE_LINUX_DEFAULT` in '''/etc/default/grub'''. Zum Schluss lässt man die GRUB-Konfiguration mit diesen Änderungen aktualisieren: {{{#!vorlage befehl sudo update-grub}}} Die o.g. Dateien sind nun kontrolliert und man weiß, wo man bei der Einrichtung hinlangen muss. = Einrichtung = Nachdem oben festgestellt wurde, dass * der gewünschte Energiesparmodus (STR und/oder STD) erreicht werden kann und * ob Kernelspace oder Userspace genutzt werden soll kann man nun mit der Einrichtung anfangen. == 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{{{#!vorlage Befehl sudo fdisk -l | grep Swap | awk '{print $1}' }}} ablesen 1. Partitionsname bzw. UUID der SWAP-Partition z.B. aus '''/etc/fstab''' ablesen: {{{#!vorlage Befehl grep swap /etc/fstab }}} 1. UUID der SWAP-Partition ("/dev/xxxy" von oben) aus der Ausgabe {{{#!vorlage Befehl ls -l /dev/disk/by-uuid }}} ablesen. 1. Die abgelesenen Informationen sollten übereinstimmen! Sonst bei [#Sonderfaelle Sonderfälle] unten weitermachen 1. Ü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). 1. initrd aktualisieren: {{{#!vorlage Befehl sudo update-initramfs -u }}} 1. System neu starten und STD testen. 1. Wenn Fehler auftreten, dann bei [#Fehlersuche 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): {{{#!vorlage Befehl 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`: {{{#!vorlage Befehl 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 1. Partitionsname aus der Ausgabe von {{{#!vorlage Befehl sudo fdisk -l }}} ablesen 1. Partitionsname bzw. UUID-Identifier der Partition aus '''/etc/fstab''' ablesen 1. UUID-Identifier aus der Ausgabe von {{{#!vorlage Befehl ls -l /dev/disk/by-uuid }}} ablesen (Vergleich mit Ausgabe von ``sudo fdisk –l``) 1. Ü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). 1. initrd aktualisieren: {{{#!vorlage Befehl sudo update-initramfs –u }}} 1. System neu starten und STD testen. 1. Wenn Fehler auftreten, dann bei [#Fehlersuche 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: {{{#!vorlage Befehl 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 [#Suspend-To-Disk 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. = Fehlersuche = {{{#!vorlage Hinweis In der Datei "/etc/default/grub" steht typischerweise bei dem Wert GRUB_CMDLINE_LINUX_DEFAULT eingetragen "quiet splash". Das unterdrückt Bootmeldungen und zeigt einen graphischen Splashscreen an. Wird dieser Eintrag geändert in "noplymouth", verschwindet der Splashscreen und alle Bootmeldungen werden sichtbar. Das ist gelegentlich hilfreich, um zu sehen, wo es "hakt". }}} == 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: {{{#!vorlage Befehl 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: || '''Fehlerursache - Kategorie''' || <-6 cellstyle="background-color: #E2C890;" :> '''Beschreibung von Maßnahmen''' || || [#Module-vor-SUSPEND-entladen-nach-RESUME-wieder-laden Module ] || Module, die beim SUSPEND entladen und beim RESUME wieder geladen werden müssen. \\ '''Beispiele:''' WLAN-Karten, Netzwerk-Karten, Bluetooth-Geräte, USB-Geräte, ... || || [#Dienste-vor-SUSPEND-stoppen-nach-RESUME-wieder-starten Dienste] || Manche Dienste verhindern das Entladen von Modulen. Daher müssen Dienste beim SUSPEND gestoppt und beim RESUME wieder gestartet werden. \\ '''Beispiel:''' USV-Dienst verhindert das Entladen von USB-Modulen || || [#Grafikkartentreiber-und-Desktop-Effekte Grafik] || Bei bestimmten Grafik-Einstellungen kann es vorkommen, dass SUSPEND ebenso nicht möglich ist.\\ '''Beispiele:''' * radeon statt fglrx verwenden * Nvidia-Treiber Version 180: * durch andere Version ersetzen * In '''xorg.conf''' eintragen: {{{ Option "NvAGP" "1" }}} * die Option `"NoDRI"` aus '''xorg.conf''' enfernen || || [#STD-wird-ausgefuehrt-kein-RESUME SWAP-Einstellung falsch] || Verschiebt man die SWAP-Partition, ohne den Eintrag in der Konfigurationsdatei für RESUME anzupassen, so kann der Kernel das STD-Image nicht finden. || || [#ACPI-abgeschaltet ACPI abgeschaltet] || Manche Systeme booten nur dann, wenn ACPI abgeschaltet wird (acpi=off, dann ist die Nutzung von ACPI-Energiesparmodi nicht möglich), oder das BIOS aktualisiert wird. || || Hardware-Besonderheiten || Bei manchen Systeme kann der Linux-Kernel nicht fehlerfrei direkt die Energiesparmodi steuern, durch Verwendung der entsprechenden BIOS-Funktionen (siehe [:Bootoptionen#Energiespar-Bootoptionen:Energiespar-Bootoptionen] können diese Modi aber u.U. trotzdem (indirekt) umgeschaltet werden. || == 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: {{{#!vorlage Befehl 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: {{{#!vorlage Befehl 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. || '''Version''' || '''Module''' || '''Weiteres''' || || '''Ubuntu 10.10''' || xhci_hcd tpm_tis r8187se || '''xhci_hcd:''' Treiber für [http://www.linux-magazin.de/NEWS/Specs-fuer-XHCI-sind-online eXtensible Host Controller] {de} USB 1.0 - 3.0 \\ '''tpm_tis:''' Treiber für [wikipedia:Trusted_Platform_Module:TPM-Chip], voraussichtlich ab Kernel 2.6.37 gefixt \\ '''r8187se:''' Treiber für eine Notebook-WLAN-Karte von Realtek || || '''Ubuntu 10.04''' || xhci || '''xhci:''' Treiber für [http://www.linux-magazin.de/NEWS/Specs-fuer-XHCI-sind-online eXtensible Host Controller] USB 1.0 - 3.0 || || '''Ubuntu 8.04''' || ehci-hcd uhci-hcd usbcore forcedeth ivtv ohci1394 ieee1394 bttv || || 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: {{{#!vorlage Befehl 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 [bug:212660:Launchpad] und im [post:1699512:Forum] und speziell zu Ubuntu 10.04 [post:2570901:hier]. Eine gute Anleitung, um solche Module aufzuspüren, ist hier zu finden: [ubuntu:DebuggingKernelSuspend#%22resume-trace%22%20debugging%20procedure%20for%20finding%20buggy%20drivers:"resume-trace" debugging procedure for finding buggy drivers] {en}. {{{#!vorlage Hinweis Mehr Informationen befinden sich in der Datei '''/usr/share/doc/pm-utils/HOWTO.modules'''. }}} == 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 [#pm-utils-Hooks Hook] unter Verwendung des [#Eigene-Hooks-erstellen 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 [:Archiv/Energiesparmodi_mit_ACPI#S3-im-BIOS-aktivieren:BIOS-Einstellungen] und [:Archiv/Energiesparmodi_mit_ACPI#ACPI-Kernelparameter:ACPI-Kernelparameter] kontrolliert werden. == Grafikkartentreiber und Desktop-Effekte == === Nvidia === Es wurde mehrmals festgestellt, dass der Nvidia-Treiber in der Version 180 SUSPEND verhindert. In diesem Fall sollte der Treiber durch eine ältere Version 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: 1. Von Desktop abmelden 1. Mit [[Vorlage(Tasten, Strg + Alt + F1)]] zu einer virtuellen Konsole wechseln 1. Anmelden 1. {{{#!vorlage Befehl sudo init 1}}} 1. SUSPEND oder HIBERNATE starten: {{{#!vorlage Befehl /usr/sbin/pm-suspend }}} oder {{{#!vorlage Befehl /usr/sbin/pm-hibernate }}} 1. 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 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. {{{#!vorlage Befehl 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: {{{#!vorlage Befehl 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 [topic:nach-standby-kein-ton-mehr: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: {{{#!vorlage Befehl 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 1. Die Zeile {{{ # HIBERNATE_MODE="platform" }}} einkommentieren. 1. Anstelle von `platform` hier `shutdown` eintragen. 1. 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: {{{#!vorlage Befehl 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 1. mit [[Vorlage(Tasten, Strg + Alt + F1)]] in eine virtuelle Konsole wechseln 1. Anmelden 1. Debug-Modus aktivieren: {{{#!vorlage Befehl echo 1 | sudo tee /sys/power/pm_trace }}} 1. SUSPEND oder HIBERNATE starten: {{{#!vorlage Befehl /usr/sbin/pm-suspend }}} oder {{{#!vorlage Befehl /usr/sbin/pm-hibernate }}} 1. Das System geht in SUSPEND über. 1. Wenn der Ruhezustand eingekehrt ist, dann RESUME einleiten durch Drücken der Power-Taste. 1. 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 [:Dateisystemcheck:Dateisystemchecks] durchgeführt. Nicht verunsichern lassen - einfach abwarten! 1. Sobald das System gestartet ist, mit [[Vorlage(Tasten, Strg + Alt + F1)]] zu einer virtuelle Konsole wechseln 1. Anmelden 1. {{{#!vorlage Befehl cd /tmp dmesg > dmesg.txt grep "hash matches" dmesg.txt > dmesg_hash_matches.txt }}} 1. 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 [#Module-vor-SUSPEND-entladen-nach-RESUME-wieder-laden weiter oben]. {{{#!vorlage Hinweis Mehr Informationen befinden sich in der Datei '''/usr/share/doc/pm-utils/README.debugging'''. }}} {{{#!vorlage Experten Man kann auch das Original der Datei '''/usr/lib/pm-utils/pm-action''' speichern (z.B. als '''/usr/lib/pm-utils/pm-action.bak''') und dann Änderungen an dieser Datei vornehmen, z.B. ``set -x`` in der zweiten Zeile im Skript eintragen. Dann wird ersichtlich, was das Skript macht, da jeder Aufruf/Befehl inkl. Ergebnis ausgegeben wird. }}} == 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. {{{#!code bash #!/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#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: {{{#!vorlage Befehl 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 [mark] 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[/mark] }}} 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: {{{#!vorlage Befehl sudo -i }}} Nun deaktiviert man das erste Gerät {{{#!vorlage Befehl echo USB0 > /proc/acpi/wakeup }}} und kontrolliert das Ergebnis mit: {{{#!vorlage Befehl 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 [mark] 13 USB0 S3 *disabled pci:0000:00:04.0[/mark] 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): {{{#!vorlage Befehl echo USB0 > /proc/acpi/wakeup }}} Zum Schluss muss dann noch die Root-Shell verlassen werden: {{{#!vorlage Befehl exit }}} = Links = * [http://pm-utils.freedesktop.org/wiki/ pm-utils Wiki auf freedesktop.org] {en} * [http://hal.freedesktop.org/quirk/quirk-suspend-index.html HAL Sleep Quirks] {en} * [topic:pm-suspend-in-hardy-perfekt-in-lucid-nur-1x-r:Lucid USB verhindert kernel-suspend] * [https://wiki.archlinux.org/index.php/Power_management/Suspend_and_hibernate#Instantaneous_wakeups_from_suspend Instantaneous wakeups from suspend ] {en} * Anleitungen im Ubuntu-Wiki: * [ubuntu:DebuggingKernelSuspend:DebuggingKernelSuspend] {en} * [ubuntu:DebuggingGNOMEPowerManager:DebuggingGNOMEPowerManager] {en} * [ubuntu:DebuggingACPI:DebuggingACPI] {en} * [ubuntu:UnderstandingSuspend:UnderstandingSuspend] {en} * Sonstiges: * [opensuse:Fehlersuche_in_ACPI_Suspend:Fehlersuche in ACPI Suspend auf opensuse.org] {de} * [http://en.opensuse.org/Pm-utils Über pm-utils bei opensuse] {en} * [http://de.opensuse.org/Pm-utils Über pm-utils bei opensuse] {de} * [:Archiv/Skripte/Auto_SUSPEND:Automatischer SUSPEND für SSH-Server] mit pm-utils * [http://www.loggn.de/linux-xbmc-aus-bereitschaftsmodus-per-mce-fernbedienung-aufwecken/ XBMC aus Bereitschaftsmodus per MCE-Fernbedienung aufwecken] {de} * [http://www.loggn.de/linux-probleme-nach-dem-bereitschaftsmodus-fernbedienung-netzwerk-und-sound-funktionieren-nicht/ Probleme nach dem Bereitschaftsmodus – Fernbedienung, Netzwerk und Sound funktionieren nicht] {de} #tag: Hardware, System, Bereitschaft, Ruhezustand, suspend, hibernate