Resume from standby works with "pm-suspend" but not through HAL

[Bernhard Gehl]

Binary package hint: gnome-power-manager

Suspending/resuming with "/etc/acpi/sleep.sh" script works, as does suspend/resume over HAL via "pm-suspend". However, when suspending using the gnome-power-manager (via panel applet, power button or similar events), after resume only a scrambled screen output (slightly reminding of the VESA usplash screen) appears and the system is completely inresponsive.

Hardware: Radeon Mobility x1600 (in a LG S1 Dual Pro)
Ubuntu: Hardy 8.04 (current alpha)
Kernel: image 2.6.24-12.22 generic, restricted modules 2.6.24.11-12.31 generic, fglrx 7.1.0-8-3+2.6.24-11-12.31

I am completely aware that there is a long history of suspend/resume problems with fglrx (particularly bug #121653). Yet it seems that with the current version standby is technically possible and I think a lot of people being stuck with fglrx-supported graphics adapters in their notebooks would very much appreciate a working suspend mode - even if it involves some workaround or something.

Attached you find the version of the /etc/default/acpi-support configfile - if it can be of any use.

[FrejSoya (frej)]

I can confirm this. This actually fixes resume.

[FrejSoya (frej)]

So after messing around it seems that it's because acpi-support isn't used and pm-utils is.
pm-suspend works fine since it's called with no quirks, but hal on my machine set quirk.vbe_post = true.

In hal I had
'power_management.quirk.vbe_post = true' because of 20-video-quirk-pm-apple.fdi changing it to false fixes resume/supend from System->Quit.

So this bug is not in gnome-power-manager but in hal (!).

[Bernhard Gehl (bernhard-gehl)]

Thanks for the hint - alas, it doesn't apply to my problem.

"lshal | grep quirk" gives empty results and manually adding "power_management.quirk.vbe_post = false" via a .fdi file does not improve the situation. No resume after suspend from g-p-m.

However I am now pretty sure that for some reason, gnome tries to use vbetool: When I run pm-suspend with --quirk-vbe-post, I get exactly the same scrambled screen/memory content as from the g-p-m suspend.

So HAL probably is not the problem - but who is?

[Andreas Wenning (andreas-wenning)]

Hi.

You can see more about HAL and quirks here:
http://people.freedesktop.org/~hughsient/quirk/quirk-suspend-index.html

There are more quirks than those two. Try to look here for a list:
http://people.freedesktop.org/~hughsient/quirk/quirk-suspend-try.html

If you find a combo that works with your system, I would strongly recommend reporting it to HAL (see first link); and reporting it as a bug against HAL in launchpad with relevant information.

[Bernhard Gehl (bernhard-gehl)]

Well, I played around with the quirks a litte (nice collection of useful info, thanks!) but I am not sure if that leads to anything since "pm-suspend" without any called quirks suspends and resumes fine - so no quirks should be necessary, right?

Somewhere in one of the fdi files I found some LG-specific settings (S3 stuff), tried them and found my laptop crashing badly. Also I experimented with the ".none" antiquirk but to no avail. It still seems like someone/-thing calls for vbe_post when I call the suspend function of g-p-m even though HAL knows what to do without any quirks. (Oh, by the way: Suspend/Resume works fine with the VESA driver.)

Is there a way to track that down? Any typical culprits besides HAL?

Sorry for being difficult, but this bug is seriously gnawing at my nerves...

[Andreas Wenning (andreas-wenning)]

@Bernhard

Using "lshal | grep quirk" you can see which quirks HAL has enabled for your computer. If you suspend using pm-suspend and these quirks you should see exactly the same behaviour as when using the gnome logout menu.

[Jonathan Anderson (jonathan-anderson)]

I'm using a Dell Inspiron 6400/E1505 with an ATI Mobility Radeon X1400. pm-supend works fine, but the KDE guidance-power-manager suspend doesn't.

I've attached a patch file which gets rid of HAL quirks for me (lshal | grep quirk shows power_management.quirk.none = true), but KDE's suspend still doesn't work. Perhaps KDE uses something other than HAL for suspend?

[Bernhard Gehl (bernhard-gehl)]

@awen

That's what keeps puzzling me: "lshal | grep quirk" shows no results - so g-p-m should go down to suspend (using hal) without quirks and therefore just like "pm-suspend" without any arguments. However, it shows a scrambled VESA-buffer-window just as I get it when using "pm-suspend --quirk-vbe-post". This is why I suspected g-p-m and not HAL, even though it is the obvious culprit for this kind of hangup.

[Andreas Wenning (andreas-wenning)]

I know for sure, that kde-power-manager uses HAL for suspending (not sure with gnome-p-m, but it should use it afaik).

There is also a "/var/log/pm-suspend.log" that might be interesting to look at; especially if there is any difference when you suspend using pm-suspend or [k|g]-p-m.

[Bernhard Gehl (bernhard-gehl)]

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?

[Bernhard Gehl (bernhard-gehl)]

I ran "dbus-monitor" while suspending via dbus-command. The last (relevant - pidgin is kind of chatty) few lines are attached as a log file.

[Andreas Wenning (andreas-wenning)]

Bernhard.

Is the attached pm-suspend.log from suspending from pm-suspend or g-p-m? Do you have a log from the other case?

[FrejSoya (frej)]

Bernhard, i got intrigued that that lshal |grep quirks showed nothing and it still uses vbe-post.

I found the cause (A weird ubuntu patch).
88_change_pm_quirk_policy.patch changes the logic in a distinct way. For example vbe-post quirk.

-[ "$HAL_PROP_POWER_MANAGEMENT_QUIRK_VBE_POST" = "true" ] && QUIRKS="$QUIRKS --quirk-vbe-post"
+[ "$HAL_PROP_POWER_MANAGEMENT_QUIRK_VGA_MODE_3" != "false" ] && QUIRKS="$QUIRKS --quirk-vbe-post"

Normal hal: enabling quirk requires the value to be true. Any other value disables the quirk.
With patch: disabling the quirk requires to be false. Any other value enables the quirk.
It's whitelist vs. blacklist. But the fdi files are upstream expects to enable quirks only when needed.

So values like "foobar" or null (or whatever bash unset variables evalutes to) causes the quirk to be enabled with this patch.

The changelog even says:
   - 88_change_pm_quirk_policy.patch: Patch by Matthew Garret, undocumented,
     non-obvious purpose.

Applying a patch and knowing is has a "non obvious purpose" shouldn't happen, even if it's from Matthew Garret :).

[Bernhard Gehl (bernhard-gehl)]

Good point - I was not aware that g-p-m also uses the pm-suspend file. The file I attached was probably from g-p-m, so I deleted it and ran pm-suspend. The logfile (attached) shows a difference because there are also (surprise) OKs from the resume hooks...

[Bernhard Gehl (bernhard-gehl)]

@FrejSoya:
So it's opt-out rather than opt-in? Gee! I thought that only applied to spam... ;-)

Ok, let me see. The negative logic means, I have to initialize every single quirk with "false" to get a pristine quirk-free suspend. Would the fdi-file attached do the job? (I'll try in a minute...)

[Andreas Wenning (andreas-wenning)]

I've done a build of the current HAL with 88_change_pm_quirk_policy.patch reverted.

You can find it build for i386 in http://awen.dk/packages/ ... how dows that one act out?

[Andreas Wenning (andreas-wenning)]

I've also added pm-suspend to the above link. Have a backup of your originale pm-suspend and replace it with this; your machine will not suspend but the quirks is logged to /root/pm-suspend.log .

[Andreas Wenning (andreas-wenning)]

Not a good idea to revert that patch it seems. Looks like som pretty sensible defaults.

Try to have a look in the file "/usr/share/hal/fdi/information/10freedesktop/". There is some 20* files that describes different laptops/computers; that's where the patch for your specific computer should be.

[Bernhard Gehl (bernhard-gehl)]

@FrejSoya
Well, lshal gives the following:

  power_management.quirk.dpms_on = false (bool)
  power_management.quirk.dpms_suspend = false (bool)
  power_management.quirk.radeon_off = false (bool)
  power_management.quirk.s3_bios = false (bool)
  power_management.quirk.s3_mode = false (bool)
  power_management.quirk.vbe_post = false (bool)
  power_management.quirk.vbemode_restore = false (bool)
  power_management.quirk.vbestate_restore = false (bool)
  power_management.quirk.vga_mode_3 = false (bool)

However, suspend via g-p-m doesn't work...

@awen
Thanks - one more nice solution! :-) Seems that there are quite some quirks enabled (logfile enclosed).
I'll grab the hal build in a minute and try it out....

[Bernhard Gehl (bernhard-gehl)]

@awen

Ok, I've finished celebrating the first successful suspend/resume with g-p-m since I switched to Linux... :-)
a) /root/pm-suspend.log is empty when using your (quite elegant) pm-suspend script
b) with the original pm-suspend symlink, suspend AND resume work just fine!

So as far as I am concerned, everything is fine. Perhaps just the "negative logic" lines of the patch should be cancelled with the "sensible" rest being left in place? Will your changes propagate to Ubuntu? Can I do anything?

Concerning the fdi file for my computer, matching vendor, product ID and "linux.driver.info" is no problem - but my setup doesn't need any quirks and even if I explicitly switch off all of them (see above), the dbus-suspend-call seems to apply some of them... Furthermore, I suspect that there are several more people affected by this bug. However, most fglrx-users are used to broken suspends and likely to blame ati, the kernel or X - but suffer from a simple case of "well-meant patch syndrome".

Attached: pm-suspend.log (not from the diagnostic script) from suspending/resuming with g-p-m!

[Andreas Wenning (andreas-wenning)]

@Bernhard
Can you attach the fdi-file that made it work with g-p-m? I'll try taking a closer look at it.

The "negative logic" is actually what makes the sensible defaults; so I'm quite sure that will not be included (a very large change so late in development).

[Nikolaus Filus (nfilus)]

As this bug is a duplicate of bug #198808 you all will find the root cause and a solution there.
As quick info (until a corrected hardy version appears):

1a) revert the logic in /usr/lib/hal/scripts/linux/hal-system-power-suspend-linux to upstream *OR*
 b) revert 88_change_pm_quirk_policy.patch in source package *OR*
 c) use package from https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/202814/comments/17

2. test suspend/resume and find the right quirls for your system

3. POST YOUR SET OF NEEDED QUIRKS TO HAL MAILINGLIST (together with lshal -lu /org/freedesktop/Hal/devices/computer)

4. smile and be happy about fixing suspend/resume :)

[Bernhard Gehl (bernhard-gehl)]

As I already tried to explain: My hardware doesn't seem to need any quirks to successfully suspend and resume. However, even with all quirks set to "false" (see above), HAL still wanted to use some quirks (including vbe_post) crashing the system. The only way (besides reverting the patch in source) to get rid of the problem was to use awen's package (thanks a thousand times!).

Should I post a fdi-file for my system with the ".none" quirk, I found in some of the other fdis? Well, perhaps I'll try the DPMS options to get rid of some ugly grey stripes during suspend...

Anyways - I read in bug #198808 that the Ubuntu folks decided against the patch for Hardy, so I'll be safe and happy since I (personally) don't consider the negative logic a very good idea. ("Assume by default that new hardware has every bug we ever considered (until a new fdi file is written). At the same time force every new quirk implemented by hal on every old system until the fdis are updated." - Or did I get that wrong?)

Be it as it may: Thanks to your help, I can enjoy my laptop at its full value now and proceed to step 4.

Thanks again!

[sam88824 (sam88824)]

 have used ubuntu since dapper 6.06 and standby and hibernate never worked. I am now using ubuntu 8.04 on three different compaq presario none will wake after going to standby i have to unplug the machine and plug it back in because power button will do nothing. Moving the mouse should wake from standby but does not.