Archiv für Januar, 2011

Notebook wacht bei Akkubetrieb nicht aus dem Standby-Modus (Suspend) auf

17. Januar 2011 von edgar

Heute habe ich ein sehr seltsames Problem bei meinem Notebook behoben: Im Akkubetrieb erwachte es nicht aus dem Standby-Modus, und zwar weder aus S3 (Suspend to Disk, STD) noch aus S4 (Suspend to RAM, STR). Naja, eigentlich wachte das Notebook schon auf, ist aber jedesmal kurz danach eingefroren (freeze). Im Netzbetrieb zeigten sich jedoch keinerlei Probleme.

Der Vollständigkeit halber: Bei dem Notebook handelt es sich um ein Belinea o.book 1304 mit einer Realtek R8187SE WLAN-Karte, welche das Problem verursachte.

Nachdem pm_trace nichts brauchbares lieferte, sah ich mir die Logdateien erneut an. In /var/log/syslog fand ich einen Hinweis auf den Netzwerk-Manager:


Jan 17 20:22:53 discovery NetworkManager[961]: wake requested (sleeping: yes enabled: yes)
Jan 17 20:22:53 discovery NetworkManager[961]: waking up and re-enabling...
Jan 17 20:22:53 discovery NetworkManager[961]: (eth0): now managed
Jan 17 20:22:53 discovery kernel: [26104.861236] r8169 0000:02:00.0: eth0: link down
Jan 17 20:22:53 discovery NetworkManager[961]: (eth0): device state change: 1 -> 2 (reason 2)
Jan 17 20:22:53 discovery NetworkManager[961]: (eth0): bringing up device.
Jan 17 20:22:53 discovery NetworkManager[961]: (eth0): preparing device.
Jan 17 20:22:53 discovery NetworkManager[961]: (eth0): deactivating device (reason: 2).
Jan 17 20:22:53 discovery NetworkManager[961]: Unmanaged Device found; state CONNECTED forced. (see http://bugs.launchpad.net/bugs/191889)
Jan 17 20:22:53 discovery NetworkManager[961]: Unmanaged Device found; state CONNECTED forced. (see http://bugs.launchpad.net/bugs/191889)
Jan 17 20:22:53 discovery NetworkManager[961]: (wlan0): now managed
Jan 17 20:22:53 discovery NetworkManager[961]: (wlan0): device state change: 1 -> 2 (reason 2)
Jan 17 20:22:53 discovery NetworkManager[961]: (wlan0): bringing up device.
Jan 17 20:22:53 discovery kernel: [26104.861678] ADDRCONF(NETDEV_UP): eth0: link is not ready
Jan 17 20:22:53 discovery kernel: [26104.862500] r8180: Bringing up iface
Jan 17 20:22:53 discovery kernel: [26104.881316] Skipping EDID probe due to cached edid
Jan 17 20:22:54 discovery kernel: [26105.062340] r8180: Card successfully reset
Jan 17 20:22:54 discovery kernel: [26105.811381] r8180: WIRELESS_MODE_G
Jan 17 20:22:54 discovery kernel: [26105.811383]
Jan 17 20:22:54 discovery NetworkManager[961]: (wlan0): preparing device.
Jan 17 20:22:54 discovery NetworkManager[961]: (wlan0): deactivating device (reason: 2).
Jan 17 20:22:54 discovery kernel: [26105.828079] ADDRCONF(NETDEV_UP): wlan0: link is not ready
Jan 17 20:22:54 discovery NetworkManager[961]: (wlan0): supplicant interface state: starting -> ready
Jan 17 20:22:54 discovery NetworkManager[961]: (wlan0): device state change: 2 -> 3 (reason 42)

Dies war der letzte Eintrag vor dem Einfrieren (und damit vor dem Reboot).

Testweise habe ich den Netzwerk-Manager vor dem Energiesparmodus über /etc/init.d/network-manager stop angehalten und siehe da: Der Computer erwachte aus dem Standby. Nach dem Starten des Netzwerk-Manager fror er prompt wieder ein.

Die üblichen Verdächtigen bei Fehler dieser Art sind fehlerhafte Treiber. Deshalb habe ich das Kernelmodul meiner WLAN-Karte (r8187se) entsprechend einer Anleitung von Ubuntuusers in die Datei /etc/pm/config.d/unload_module folgendermaßen eingefügt:

SUSPEND_MODULES="$SUSPEND_MODULES r8187se"

Nachdem diese Datei mit sudo chmod +x /etc/pm/config.d/unload_module ausführbar gemacht wurde, funktioniert der Standbymodus wie gewohnt auch bei meinem Notebook.

Natürlich können auch andere Treiber ein Problem dieser Art hervorrufen. Ein Mögliches Vorgehen ist, sich mit sudo lsmod alle Kernelmodule anzeigen zu lassen und diese durch Eintragen in unload_module der Reihe nach darauf hin zu testen, ob sie das Problem verursachen.



css.php