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!
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 \ org.freedesktop .PowerManagemen t \ method_ call \ timeout= 2000 \ freedesktop/ PowerManagement \ freedesktop. PowerManagement .Suspend
--dest=
--type=
--print-reply \
--reply-
/org/
org.
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?