After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 356441 - suspend behavior erratic
suspend behavior erratic
Status: RESOLVED NOTGNOME
Product: gnome-power-manager
Classification: Deprecated
Component: gnome-power-manager
2.16.x
Other All
: Normal normal
: ---
Assigned To: GNOME Power Manager Maintainer(s)
GNOME Power Manager Maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2006-09-17 20:00 UTC by Jean-François Fortin Tam
Modified: 2006-09-19 07:23 UTC
See Also:
GNOME target: ---
GNOME version: 2.15/2.16


Attachments
acpid log file, if that can be of help (5.48 KB, application/octet-stream)
2006-09-17 20:08 UTC, Jean-François Fortin Tam
Details

Description Jean-François Fortin Tam 2006-09-17 20:00:46 UTC
Please describe the problem:
I cannot get a consistent result using the suspend function of gnome power manager in GNOME 2.16 with an Acer TravelMate 2428 (2420 series) laptop.

I would gladly like, to the extent of my limited knowledge, to provide as much information as I can to determine the cause of the problem, but you have to tell me what I need to look for to make this bug report useful :)

Steps to reproduce:
Use suspend button either from the gnome shutdown dialog, or using gnome power manager's tray icon contextual menu.

Actual results:
Sometimes the laptop happily suspends (the power led becomes orange, the screen turns off, the hard drives and all the rest go to sleep peacefully), but in some cases, it does not.

The problem is that I cannot figure out the logic behind the failures.

Expected results:
Always suspend successfully or provide me with information as to why it did not do so.

Does this happen every time?
No. That is the problem.

Other information:
This laptop uses an intel 915 chipset. It has a realtek (I think) wired NIC, and an intel ipw2200 integrated wifi card. I notice that the behavior of the network is inconsistent as well, meaning that after coming back from suspend, the intel wifi may be considered as a "wired" network interface by network-manager.

Possible causes? :
- battery
- wifi + wired network
- number of tries
- the software itself?

Please help me eliminate causes. Oh, and I ran my tests without the battery inside the laptop, but it happens with the battery too.
Comment 1 Jean-François Fortin Tam 2006-09-17 20:08:39 UTC
Created attachment 72949 [details]
acpid log file, if that can be of help
Comment 2 Richard Hughes 2006-09-17 20:25:17 UTC
Does:

dbus-send --system --print-reply --dest=org.freedesktop.Hal \
/org/freedesktop/Hal/devices/computer \
org.freedesktop.Hal.Device.SystemPowerManagement.Suspend \
int32:0

always work? That's the command g-p-m uses to suspend the computer.

R.
Comment 3 Jean-François Fortin Tam 2006-09-17 22:17:06 UTC
I tried that command, it did not work on a fresh boot (but using suspend from gnome power manager works.. what's going on?)

jeff@kaname:~$ dbus-send --system --print-reply --dest=org.freedesktop.Hal org/freedesktop/Hal/devices/computer 
org.freedesktop.Hal.Device.SystemPowerManagement.Suspend int32:0
8042: arguments to dbus_message_new_method_call() were incorrect, assertion "_dbus_check_is_valid_path (path)" failed in file dbus-message.c line 
797.
This is normally a bug in some application using the D-Bus library.
8042: arguments to dbus_message_set_auto_start() were incorrect, assertion "message != NULL" failed in file dbus-message.c line 2363.
This is normally a bug in some application using the D-Bus library.
Couldn't allocate D-Bus message

jeff@kaname:~$ sudo dbus-send --system --print-reply --dest=org.freedesktop.Hal org/freedesktop/Hal/devices/computer 
org.freedesktop.Hal.Device.SystemPowerManagement.Suspend int32:0
8057: arguments to dbus_message_new_method_call() were incorrect, assertion "_dbus_check_is_valid_path (path)" failed in file dbus-message.c line 
797.
This is normally a bug in some application using the D-Bus library.
8057: arguments to dbus_message_set_auto_start() were incorrect, assertion "message != NULL" failed in file dbus-message.c line 2363.
This is normally a bug in some application using the D-Bus library.
Couldn't allocate D-Bus message
Comment 4 Richard Hughes 2006-09-17 22:29:26 UTC
You typed "org/freedesktop/Hal/devices/computer" -- you want to use "/org/freedesktop/Hal/devices/computer"
Comment 5 Jean-François Fortin Tam 2006-09-17 22:49:57 UTC
Interesting. It suspends and resumes fine, but outputs this message:
Error org.freedesktop.Hal.Device.UnknownError: An unknown error occured

So far, there is no problem suspending/resuming. But as I said, I am not able to reproduce it at will :| does that error tell you anything?
Comment 6 Jean-François Fortin Tam 2006-09-17 23:36:26 UTC
I just came back from dinner (so the computer was powered on in a normal state for maybe half an hour) and tried to suspend. It refuses to suspend (shoots me back to my desktop after a few seconds), but the error message is the same.
Comment 7 Richard Hughes 2006-09-18 20:23:39 UTC
You might want to check out /var/log/messages and see what that tells you. If the` hal method fails then it's probably a distro or HAL bug and not a g-p-m bug, sorry.
Comment 8 Jean-François Fortin Tam 2006-09-19 00:03:29 UTC
Okay, I could file this against my distro's bug tracker, but where do I file bugs on HAL (I mean in HAL's bugzilla if such a thing exists)? What should I look or grep for inside the messages log file? I don't really know how to interpret what is in there.

And thank you for your help :)
Comment 9 Richard Hughes 2006-09-19 07:23:05 UTC
Hal has a bugzilla module on freedesktop.org

You'll want to be familar with hal-system-power-suspend, wherever that file exists on your computer.