Log für Supend2RAM

[steos]

Morgen!

Gibt's eine Möglichkeit Problemen beim Supend2RAM auf die Spur zu kommen, z.B. ein Log-File? Manchmal will mein Notebook einfach nicht in den Suspend-Modus gehen, mal geht's mal geht's nicht. Ich ich hab' keine Idee, woran's liegen könnte.

Wäre für Hinweise dankbar. LG,
steos

[Kokopelli]

How to get s2ram working
~~~~~~~~~~~~~~~~~~~~~~~~
2006 Linus Torvalds
2006 Pavel Machek

1) Check suspend.sf.net, program s2ram there has long whitelist of
"known ok" machines, along with tricks to use on each one.

2) If that does not help, try reading tricks.txt and
video.txt. Perhaps problem is as simple as broken module, and
simple module unload can fix it.

3) You can use Linus' TRACE_RESUME infrastructure, described below.

Using TRACE_RESUME
~~~~~~~~~~~~~~~~~~

I've been working at making the machines I have able to STR, and almost
always it's a driver that is buggy. Thank God for the suspend/resume
debugging - the thing that Chuck tried to disable. That's often the _only_
way to debug these things, and it's actually pretty powerful (but
time-consuming - having to insert TRACE_RESUME() markers into the device
driver that doesn't resume and recompile and reboot).

Anyway, the way to debug this for people who are interested (have a
machine that doesn't boot) is:

- enable PM_DEBUG, and PM_TRACE

- use a script like this:

#!/bin/sh
sync
echo 1 > /sys/power/pm_trace
echo mem > /sys/power/state

to suspend

- if it doesn't come back up (which is usually the problem), reboot by
holding the power button down, and look at the dmesg output for things
like

Magic number: 4:156:725
hash matches drivers/base/power/resume.c:28
hash matches device 0000:01:00.0

which means that the last trace event was just before trying to resume
device 0000:01:00.0. Then figure out what driver is controlling that
device (lspci and /sys/devices/pci* is your friend), and see if you can
fix it, disable it, or trace into its resume function.

For example, the above happens to be the VGA device on my EVO, which I
used to run with "radeonfb" (it's an ATI Radeon mobility). It turns out
that "radeonfb" simply cannot resume that device - it tries to set the
PLL's, and it just _hangs_. Using the regular VGA console and letting X
resume it instead works fine.

[steos]

Sorry für die späte Rückmeldung, mußte mich kurzfristig der allgemeinen Grippewelle anschließen...

Also heute bin ich (hoffe ich jedenfalls) der Ursache ein wenig näher gekommen: Nachdem es zwischenzeitlich keine Probleme gegeben hat, wollte mein Schleppi etwas unerwartet wieder einmal nicht in den Suspend2RAM Mode.

Testweise habe ich dann mal' über [Strg][Alt][Backspace] den X-Server abgeschossen, der danach automatisch wieder gestartet wurde. Danach ging Suspend2RAM wieder...

Das Prob dürfte also entweder bei KDE oder X.Org liegen und vermutlich nicht - wie zuerst von mir angenommen - beim Kernel.