Ok, I realize how much there is, I do not know about my system (even
though location and file name of the log are perfectly logical...).
Alas, the pm-suspend.log (see attached) to my eyes does not show
anything but "OK"-type status messages.
Anyways, I dug around a little in the g-p-m documentation and found the
dbus-calls that (I think) are used for suspending. So I tried running
one of those "by hand" to find out, if g-p-m does its job right. To my
surprise, the dbus-send operation (see below) resulted in exactly the
same suspend-resume crash, I experience when using g-p-m!
dbus-send --session \
--dest=org.freedesktop.PowerManagement \
--type=method_call \
--print-reply \
--reply-timeout=2000 \
/org/freedesktop/PowerManagement \
org.freedesktop.PowerManagement.Suspend
Therefore, g-p-m is obviously not the culprit - but who is it? dbus? Can
dbus call hal in a way that does not suspend like "pm-suspend" does?
** Attachment added: "pm-suspend.log"
http://launchpadlibrarian.net/12727069/pm-suspend.log
--
Resume from standby works with "pm-suspend" but not with standard ubuntu/gnome
actions (with fglrx-driver from restricted modules)
https://bugs.launchpad.net/bugs/202814
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
