Re: tracking down suspend/hibernate bugs?
Matthew Garrett wrote: > On Mon, Jan 14, 2008 at 11:10:49AM -0800, Matt Price wrote: > >> sudo pm-suspend > > Right, so it sounds more like the issue here is that we're passing > quirks that are breaking your system. For reference, the quirks that are > used by default on Ubuntu are currently: > > --quirk-dpms-on > --quirk-vbestate-restore > --quirk-vbemode-restore > --quirk-vga-mode3 > --quirk-vbe-post > --quirk-reset-brightness > > If you pass those, does it fail? If so, can you try to figure out which > one is causing it? > On my Dell M1710 using the nvidia driver, --quirk-vbe-post causes failure to resume. The rest don't seem to cause any harm (but aren't needed). -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: tracking down suspend/hibernate bugs?
Lars Wirzenius schrieb: > https://wiki.ubuntu.com/UnderstandingSuspend might of some help to some > people. Thanks, that's a great start, which could be improved by documenting the changes made in hardy (that would improve debugging feedback before the relase). The next time I'll have troube with suspending, I'll try to add some bits that differentiate Ubuntu's mechanism from competing mechanism such as uswsusp and tuxonice. Cheers Paulus -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: tracking down suspend/hibernate bugs?
On to, 2008-01-17 at 11:59 +0100, Paulus Esterhazy wrote: > It would be *very* helpful if a developer who really knows this stuff > could write a document on the Wiki detailing how this process works for > hardy. To users, suspend problems are opaque, because there often are no > logs readily available. Often, it's very hard to tell which piece of the > system is causing the lock-up. https://wiki.ubuntu.com/UnderstandingSuspend might of some help to some people. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: tracking down suspend/hibernate bugs?
Matt Price schrieb: > hi, > > just upgraded to hardy and suspend-to-ram is broken again (as in feisty > & other releases) i'm trying to figure out, again, how to track down > this bug but i'm not entirely sure what the current chain of events is > in the suspend process. can someone point me to a location where the > process is described? or suggest best practice for finding bugs of this > nature (in which resume is impossible, so messages e.g. from dmesg > or /var/log/messages don't get captured? It would be *very* helpful if a developer who really knows this stuff could write a document on the Wiki detailing how this process works for hardy. To users, suspend problems are opaque, because there often are no logs readily available. Often, it's very hard to tell which piece of the system is causing the lock-up. Cheers, Paulus -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: tracking down suspend/hibernate bugs?
Matt Price said the following on 01/15/2008 10:08 PM: >> Now this is fine for my dell with nvidia driver, but I hope it works for >> others too. >> > didn't catch this, what model is your dell? mine is latitude d820, if > you're the same maybe we've identified a laptop-specific bug. I have an E1505 (aka 6400) with nvidia 7300 go video. regards, -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: tracking down suspend/hibernate bugs?
On Tue, 2008-01-15 at 21:18 -0500, Paul S wrote: > Paul S said the following on 01/15/2008 07:18 PM: > > Matt Price said the following on 01/15/2008 05:35 PM: > ok, now I get it .. since these are based on not being false, they are > set. and "sudo lshal | grep quirk" shows that they are not set to > false. So, I just have to rearrange the order of these lines like so, > and it works: > > [ "$HAL_PROP_POWER_MANAGEMENT_QUIRK_S3_BIOS" = "true" ] && > QUIRKS="$QUIRKS --quirk-s3-bios" > [ "$HAL_PROP_POWER_MANAGEMENT_QUIRK_S3_MODE" = "true" ] && > QUIRKS="$QUIRKS --quirk-s3-mode" > [ "$HAL_PROP_POWER_MANAGEMENT_QUIRK_DPMS_SUSPEND" = "true" ] && > QUIRKS="$QUIRKS --quirk-dpms-suspend" > [ "$HAL_PROP_POWER_MANAGEMENT_QUIRK_DPMS_ON" != "false" ] && > QUIRKS="$QUIRKS --quirk-dpms-on" > [ "$HAL_PROP_POWER_MANAGEMENT_QUIRK_RESET_BRIGHTNESS" != "false" ] && > QUIRKS="$QUIRKS --quirk-reset-brightness" > [ "$HAL_PROP_POWER_MANAGEMENT_QUIRK_VGA_MODE_3" != "false" ] && > QUIRKS="$QUIRKS --quirk-vga-mode3" > [ "$HAL_PROP_POWER_MANAGEMENT_QUIRK_VBE_POST" != "false" ] && > QUIRKS="$QUIRKS --quirk-vbe-post" > [ "$HAL_PROP_POWER_MANAGEMENT_QUIRK_VBEMODE_RESTORE" != "false" ] && > QUIRKS="$QUIRKS --quirk-vbemode-restore" > [ "$HAL_PROP_POWER_MANAGEMENT_QUIRK_VBESTATE_RESTORE" != "false" ] && > QUIRKS="$QUIRKS --quirk-vbestate-restore" > [ "$HAL_PROP_POWER_MANAGEMENT_QUIRK_RADEON_OFF" = "true" ] && > QUIRKS="$QUIRKS --quirk-radeon-off" > [ "$HAL_PROP_POWER_MANAGEMENT_QUIRK_NONE" = "true" ] && QUIRKS="$QUIRKS > --quirk-none" > > Now this is fine for my dell with nvidia driver, but I hope it works for > others too. > didn't catch this, what model is your dell? mine is latitude d820, if you're the same maybe we've identified a laptop-specific bug. m > regards, > > -- Matt Price [EMAIL PROTECTED] -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: tracking down suspend/hibernate bugs?
Paul S said the following on 01/15/2008 07:18 PM: > Matt Price said the following on 01/15/2008 05:35 PM: >> take a look >> at /usr/share/hal/scripts/linux/hal-syspem-power-suspend-linux & related >> scripts -- the $QUIRK variable is built up in these scripts >> progressively; all you would need to do is to alter the order in which >> that's done. you might also want to submit a patch or at least >> bugreport to upstream, as i imagine no one's especially wedded to the >> order of those quirks. > > I see this section: > > # Make a suitable command line argument so that the tools can do the > correct > # quirks for video resume. > # Passing the quirks to the tool allows the tool to not depend on HAL > for data. > QUIRKS="" > [ "$HAL_PROP_POWER_MANAGEMENT_QUIRK_S3_BIOS" = "true" ] && > QUIRKS="$QUIRKS --quirk-s3-bios" > [ "$HAL_PROP_POWER_MANAGEMENT_QUIRK_S3_MODE" = "true" ] && > QUIRKS="$QUIRKS --quirk-s3-mode" > [ "$HAL_PROP_POWER_MANAGEMENT_QUIRK_DPMS_SUSPEND" = "true" ] && > QUIRKS="$QUIRKS --quirk-dpms-suspend" > [ "$HAL_PROP_POWER_MANAGEMENT_QUIRK_DPMS_ON" != "false" ] && > QUIRKS="$QUIRKS --quirk-dpms-on" > [ "$HAL_PROP_POWER_MANAGEMENT_QUIRK_VBESTATE_RESTORE" != "false" ] && > QUIRKS="$QUIRKS --quirk-vbestate-restore" > [ "$HAL_PROP_POWER_MANAGEMENT_QUIRK_VBEMODE_RESTORE" != "false" ] && > QUIRKS="$QUIRKS --quirk-vbemode-restore" > [ "$HAL_PROP_POWER_MANAGEMENT_QUIRK_VGA_MODE_3" != "false" ] && > QUIRKS="$QUIRKS --quirk-vga-mode3" > [ "$HAL_PROP_POWER_MANAGEMENT_QUIRK_VBE_POST" != "false" ] && > QUIRKS="$QUIRKS --quirk-vbe-post" > [ "$HAL_PROP_POWER_MANAGEMENT_QUIRK_RADEON_OFF" = "true" ] && > QUIRKS="$QUIRKS --quirk-radeon-off" > [ "$HAL_PROP_POWER_MANAGEMENT_QUIRK_RESET_BRIGHTNESS" != "false" ] && > QUIRKS="$QUIRKS --quirk-reset-brightness" > [ "$HAL_PROP_POWER_MANAGEMENT_QUIRK_NONE" = "true" ] && QUIRKS="$QUIRKS > --quirk-none" ok, now I get it .. since these are based on not being false, they are set. and "sudo lshal | grep quirk" shows that they are not set to false. So, I just have to rearrange the order of these lines like so, and it works: [ "$HAL_PROP_POWER_MANAGEMENT_QUIRK_S3_BIOS" = "true" ] && QUIRKS="$QUIRKS --quirk-s3-bios" [ "$HAL_PROP_POWER_MANAGEMENT_QUIRK_S3_MODE" = "true" ] && QUIRKS="$QUIRKS --quirk-s3-mode" [ "$HAL_PROP_POWER_MANAGEMENT_QUIRK_DPMS_SUSPEND" = "true" ] && QUIRKS="$QUIRKS --quirk-dpms-suspend" [ "$HAL_PROP_POWER_MANAGEMENT_QUIRK_DPMS_ON" != "false" ] && QUIRKS="$QUIRKS --quirk-dpms-on" [ "$HAL_PROP_POWER_MANAGEMENT_QUIRK_RESET_BRIGHTNESS" != "false" ] && QUIRKS="$QUIRKS --quirk-reset-brightness" [ "$HAL_PROP_POWER_MANAGEMENT_QUIRK_VGA_MODE_3" != "false" ] && QUIRKS="$QUIRKS --quirk-vga-mode3" [ "$HAL_PROP_POWER_MANAGEMENT_QUIRK_VBE_POST" != "false" ] && QUIRKS="$QUIRKS --quirk-vbe-post" [ "$HAL_PROP_POWER_MANAGEMENT_QUIRK_VBEMODE_RESTORE" != "false" ] && QUIRKS="$QUIRKS --quirk-vbemode-restore" [ "$HAL_PROP_POWER_MANAGEMENT_QUIRK_VBESTATE_RESTORE" != "false" ] && QUIRKS="$QUIRKS --quirk-vbestate-restore" [ "$HAL_PROP_POWER_MANAGEMENT_QUIRK_RADEON_OFF" = "true" ] && QUIRKS="$QUIRKS --quirk-radeon-off" [ "$HAL_PROP_POWER_MANAGEMENT_QUIRK_NONE" = "true" ] && QUIRKS="$QUIRKS --quirk-none" Now this is fine for my dell with nvidia driver, but I hope it works for others too. regards, -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: tracking down suspend/hibernate bugs?
> If I suspend my laptop, I'll lose my mouse pointer. The mouse action > is still there, but no mouse pointer, so I cant see what I'm > clicking. In a side note, my notebook, an Asus G1 suspends and hibernates nicely with hardy. []s Adilson. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: tracking down suspend/hibernate bugs?
On Tue, 2008-01-15 at 19:18 -0500, Paul S wrote: > Matt Price said the following on 01/15/2008 05:35 PM: > > paul, how did you find out that the suspend button initiates quirks in > > the order you describe? > > I edited /usr/share/hal/scripts/linux/hal-syspem-power-suspend-linux and > added a line to log the value of $QUIRKS when it was called, as follows: > > # We only support pm-utils > if [ -x "/usr/sbin/pm-suspend" ] ; then > logger "pm-utils quirks are $QUIRKS" > /usr/sbin/pm-suspend $QUIRKS > RET=$? > > then, after suspending, I just grepped /var/log/messages for "quirks" > and it was there, like this: > > paul :~$ grep quirks /var/log/messages > Jan 15 09:32:10 localhost logger: pm-suspend quirks are --quirk-dpms-on > --quirk-vbestate-restore --quirk-vbemode-restore --quirk-vga-mode3 > --quirk-vbe-post --quirk-reset-brightness > > then, I copied the quirks options and pasted into a terminal after "sudo > pm-suspend" and found it fails to resume (screen stays black) > nice. so i guess this ocnfirms that the gnome power button uses pm-utils, but i wish i could see how the hal script is called. > >> Now that I know that, is there someplace I can config which quirks are > >> called and in what order? > >> > >> > > take a look > > at /usr/share/hal/scripts/linux/hal-syspem-power-suspend-linux & related > > scripts -- the $QUIRK variable is built up in these scripts > > progressively; all you would need to do is to alter the order in which > > that's done. you might also want to submit a patch or at least > > bugreport to upstream, as i imagine no one's especially wedded to the > > order of those quirks. > > I see this section: > > # Make a suitable command line argument so that the tools can do the correct > # quirks for video resume. > # Passing the quirks to the tool allows the tool to not depend on HAL > for data. > QUIRKS="" > [ "$HAL_PROP_POWER_MANAGEMENT_QUIRK_S3_BIOS" = "true" ] && > QUIRKS="$QUIRKS --quirk-s3-bios" > [ "$HAL_PROP_POWER_MANAGEMENT_QUIRK_S3_MODE" = "true" ] && > QUIRKS="$QUIRKS --quirk-s3-mode" > [ "$HAL_PROP_POWER_MANAGEMENT_QUIRK_DPMS_SUSPEND" = "true" ] && > QUIRKS="$QUIRKS --quirk-dpms-suspend" > [ "$HAL_PROP_POWER_MANAGEMENT_QUIRK_DPMS_ON" != "false" ] && > QUIRKS="$QUIRKS --quirk-dpms-on" > [ "$HAL_PROP_POWER_MANAGEMENT_QUIRK_VBESTATE_RESTORE" != "false" ] && > QUIRKS="$QUIRKS --quirk-vbestate-restore" > [ "$HAL_PROP_POWER_MANAGEMENT_QUIRK_VBEMODE_RESTORE" != "false" ] && > QUIRKS="$QUIRKS --quirk-vbemode-restore" > [ "$HAL_PROP_POWER_MANAGEMENT_QUIRK_VGA_MODE_3" != "false" ] && > QUIRKS="$QUIRKS --quirk-vga-mode3" > [ "$HAL_PROP_POWER_MANAGEMENT_QUIRK_VBE_POST" != "false" ] && > QUIRKS="$QUIRKS --quirk-vbe-post" > [ "$HAL_PROP_POWER_MANAGEMENT_QUIRK_RADEON_OFF" = "true" ] && > QUIRKS="$QUIRKS --quirk-radeon-off" > [ "$HAL_PROP_POWER_MANAGEMENT_QUIRK_RESET_BRIGHTNESS" != "false" ] && > QUIRKS="$QUIRKS --quirk-reset-brightness" > [ "$HAL_PROP_POWER_MANAGEMENT_QUIRK_NONE" = "true" ] && QUIRKS="$QUIRKS > --quirk-none" > > but this script requires you to know the value of each of the variables, > and I haven't been able to find those variables anywhere. I can usually > follow bash scripts, but have no experience with C/C++ code, which may > be where they are set. > i don't see either. i tried this: $ dpkg -L hal | xargs grep "HAL_PROP_POWER_MANAGEMENT_QUIRK_S3_BIOS" but didn't get any helpful hits. that shouldn't matter though -- presumably the relevant variables *are* set, so the quirk gets added; by changing the order of the tests, the ordering of the quirks also ought to be affected. give it a try! matt > Do you know? > > > -- Matt Price [EMAIL PROTECTED] -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: tracking down suspend/hibernate bugs?
Matt Price said the following on 01/15/2008 05:35 PM: > paul, how did you find out that the suspend button initiates quirks in > the order you describe? I edited /usr/share/hal/scripts/linux/hal-syspem-power-suspend-linux and added a line to log the value of $QUIRKS when it was called, as follows: # We only support pm-utils if [ -x "/usr/sbin/pm-suspend" ] ; then logger "pm-utils quirks are $QUIRKS" /usr/sbin/pm-suspend $QUIRKS RET=$? then, after suspending, I just grepped /var/log/messages for "quirks" and it was there, like this: paul :~$ grep quirks /var/log/messages Jan 15 09:32:10 localhost logger: pm-suspend quirks are --quirk-dpms-on --quirk-vbestate-restore --quirk-vbemode-restore --quirk-vga-mode3 --quirk-vbe-post --quirk-reset-brightness then, I copied the quirks options and pasted into a terminal after "sudo pm-suspend" and found it fails to resume (screen stays black) >> Now that I know that, is there someplace I can config which quirks are >> called and in what order? >> >> > take a look > at /usr/share/hal/scripts/linux/hal-syspem-power-suspend-linux & related > scripts -- the $QUIRK variable is built up in these scripts > progressively; all you would need to do is to alter the order in which > that's done. you might also want to submit a patch or at least > bugreport to upstream, as i imagine no one's especially wedded to the > order of those quirks. I see this section: # Make a suitable command line argument so that the tools can do the correct # quirks for video resume. # Passing the quirks to the tool allows the tool to not depend on HAL for data. QUIRKS="" [ "$HAL_PROP_POWER_MANAGEMENT_QUIRK_S3_BIOS" = "true" ] && QUIRKS="$QUIRKS --quirk-s3-bios" [ "$HAL_PROP_POWER_MANAGEMENT_QUIRK_S3_MODE" = "true" ] && QUIRKS="$QUIRKS --quirk-s3-mode" [ "$HAL_PROP_POWER_MANAGEMENT_QUIRK_DPMS_SUSPEND" = "true" ] && QUIRKS="$QUIRKS --quirk-dpms-suspend" [ "$HAL_PROP_POWER_MANAGEMENT_QUIRK_DPMS_ON" != "false" ] && QUIRKS="$QUIRKS --quirk-dpms-on" [ "$HAL_PROP_POWER_MANAGEMENT_QUIRK_VBESTATE_RESTORE" != "false" ] && QUIRKS="$QUIRKS --quirk-vbestate-restore" [ "$HAL_PROP_POWER_MANAGEMENT_QUIRK_VBEMODE_RESTORE" != "false" ] && QUIRKS="$QUIRKS --quirk-vbemode-restore" [ "$HAL_PROP_POWER_MANAGEMENT_QUIRK_VGA_MODE_3" != "false" ] && QUIRKS="$QUIRKS --quirk-vga-mode3" [ "$HAL_PROP_POWER_MANAGEMENT_QUIRK_VBE_POST" != "false" ] && QUIRKS="$QUIRKS --quirk-vbe-post" [ "$HAL_PROP_POWER_MANAGEMENT_QUIRK_RADEON_OFF" = "true" ] && QUIRKS="$QUIRKS --quirk-radeon-off" [ "$HAL_PROP_POWER_MANAGEMENT_QUIRK_RESET_BRIGHTNESS" != "false" ] && QUIRKS="$QUIRKS --quirk-reset-brightness" [ "$HAL_PROP_POWER_MANAGEMENT_QUIRK_NONE" = "true" ] && QUIRKS="$QUIRKS --quirk-none" but this script requires you to know the value of each of the variables, and I haven't been able to find those variables anywhere. I can usually follow bash scripts, but have no experience with C/C++ code, which may be where they are set. Do you know? -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: tracking down suspend/hibernate bugs?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Monday 14 January 2008 19:10:49 Matt Price wrote: > hmmm... fooling around, i find that i can suspend pretty reliably from the > command line > sudo pm-suspend > > but that the gnome-power-manager dialog reliably fails to resume; this > despitethe fact that it seemsto be using pm-suspend, as it writes a > suspend log to /var/log/pm-suspend. not sure what's going on there. > > matt If I suspend my laptop, I'll lose my mouse pointer. The mouse action is still there, but no mouse pointer, so I cant see what I'm clicking. - -- BUGabundo :o) (``-_-´´) http://Ubuntu.BUGabundo.net Linux user #443786GPG key 1024D/A1784EBB My new micro-blog @ http://BUGabundo.net ps. My emails tend to sound authority and aggressive. I'm sorry in advance. I'll try to be more assertive as time goes by... -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHjUtvcV4wzCrhCcoRAkPKAJ9fbDSu5OEqL3qg9f/60gdNO9HSCACg4L+J pfnvFfim69Snjlf2qXylUYE= =hNot -END PGP SIGNATURE- -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: tracking down suspend/hibernate bugs?
Matthew Garrett said the following on 01/15/2008 06:02 PM: > Though, having said that, I have found various issues - I've just > uploaded a new pm-utils. It'd be nice to know if it worked for you. > OK, I'm updating daily, so when it hits the repos I'll get it, unless you have an advance copy you can send me. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: tracking down suspend/hibernate bugs?
Matthew Garrett said the following on 01/15/2008 05:42 PM: > I can't see how this can happen - the same environment variables are set > in both cases independent of the ordering. Is this repeatable? > Yes, many times. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: tracking down suspend/hibernate bugs?
On Tue, 2008-01-15 at 23:02 +, Matthew Garrett wrote: > Though, having said that, I have found various issues - I've just > uploaded a new pm-utils. It'd be nice to know if it worked for you. > i'll give it a try myself soon as it hits the archive. matt > -- > Matthew Garrett | [EMAIL PROTECTED] > -- Matt Price [EMAIL PROTECTED] -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: tracking down suspend/hibernate bugs?
Though, having said that, I have found various issues - I've just uploaded a new pm-utils. It'd be nice to know if it worked for you. -- Matthew Garrett | [EMAIL PROTECTED] -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: tracking down suspend/hibernate bugs?
I can't see how this can happen - the same environment variables are set in both cases independent of the ordering. Is this repeatable? -- Matthew Garrett | [EMAIL PROTECTED] -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: tracking down suspend/hibernate bugs?
On Tue, 2008-01-15 at 16:30 -0500, Paul S wrote: > Matthew Garrett said the following on 01/15/2008 01:59 PM: > > On Tue, Jan 15, 2008 at 09:30:13AM -0500, Paul S wrote: > > > >> This is not good. I had a kernel update so had to reboot anyway. Now > >> I find that even Fn-Esc does not work. The only way to suspend is by > >> konsole with "sudo pm-suspend" and it still works ok. The > >> kde-power-manager menu "suspend" does not work. either nor the keyboard > >> "sleep" button. > > > > Ok. Sounds like KDE is failing to respond to the sleep button signal. > > I'm afraid I've no expertise beyond this point. > > > > Ok, I switched over to gdm and gnome and have similar problems. It > suspends but does not resume. So, I've been trying to work it out in a > terminal. What I've discovered is that I can enter this and it works: > > sudo pm-suspend --quirk-dpms-on --quirk-vga-mode3 > --quirk-reset-brightness --quirk-vbe-post --quirk-vbemode-restore > --quirk-vbestate-restore > > However, when I hit the suspend button, hal initiates the quirks in this > different order: > > --quirk-dpms-on --quirk-vbestate-restore --quirk-vbemode-restore > --quirk-vga-mode3 --quirk-vbe-post --quirk-reset-brightness > paul, how did you find out that the suspend button initiates quirks in the order you describe? > > Now that I know that, is there someplace I can config which quirks are > called and in what order? > > take a look at /usr/share/hal/scripts/linux/hal-syspem-power-suspend-linux & related scripts -- the $QUIRK variable is built up in these scripts progressively; all you would need to do is to alter the order in which that's done. you might also want to submit a patch or at least bugreport to upstream, as i imagine no one's especially wedded to the order of those quirks. matt > -- Matt Price [EMAIL PROTECTED] -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: tracking down suspend/hibernate bugs?
Matthew Garrett said the following on 01/15/2008 01:59 PM: > On Tue, Jan 15, 2008 at 09:30:13AM -0500, Paul S wrote: > >> This is not good. I had a kernel update so had to reboot anyway. Now >> I find that even Fn-Esc does not work. The only way to suspend is by >> konsole with "sudo pm-suspend" and it still works ok. The >> kde-power-manager menu "suspend" does not work. either nor the keyboard >> "sleep" button. > > Ok. Sounds like KDE is failing to respond to the sleep button signal. > I'm afraid I've no expertise beyond this point. > Ok, I switched over to gdm and gnome and have similar problems. It suspends but does not resume. So, I've been trying to work it out in a terminal. What I've discovered is that I can enter this and it works: sudo pm-suspend --quirk-dpms-on --quirk-vga-mode3 --quirk-reset-brightness --quirk-vbe-post --quirk-vbemode-restore --quirk-vbestate-restore However, when I hit the suspend button, hal initiates the quirks in this different order: --quirk-dpms-on --quirk-vbestate-restore --quirk-vbemode-restore --quirk-vga-mode3 --quirk-vbe-post --quirk-reset-brightness so, if I try it in a terminal, it suspends but does not resume (same result as suspend button): sudo pm-suspend --quirk-dpms-on --quirk-vbestate-restore --quirk-vbemode-restore --quirk-vga-mode3 --quirk-vbe-post --quirk-reset-brightness Now, I believe the problem is that my nvidia driver does not support the vbetool. But, why it works in the different order is puzzling to me. Did you know that order matters? Also, I have tried and successfully resumed from: paul :~$ sudo pm-suspend --quirk-dpms-on --quirk-vbestate-restore --quirk-vbemode-restore --quirk-vga-mode3 --quirk-reset-brightness and successfully from: paul :~$ sudo pm-suspend --quirk-dpms-on --quirk-vbestate-restore --quirk-vbemode-restore --quirk-vga-mode3 --quirk-reset-brightness --quirk-vbe-post This makes me think that --quirk-vbe-post is the problem, but only is ok in certain orders. I'm not sure I have enough time to try all the combinations? Also, I have gone back to kdm and kde and have the same experience in the terminal, so there's not a problem in kde Now that I know that, is there someplace I can config which quirks are called and in what order? -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: tracking down suspend/hibernate bugs?
On Tue, Jan 15, 2008 at 09:30:13AM -0500, Paul S wrote: > This is not good. I had a kernel update so had to reboot anyway. Now > I find that even Fn-Esc does not work. The only way to suspend is by > konsole with "sudo pm-suspend" and it still works ok. The > kde-power-manager menu "suspend" does not work. either nor the keyboard > "sleep" button. Ok. Sounds like KDE is failing to respond to the sleep button signal. I'm afraid I've no expertise beyond this point. -- Matthew Garrett | [EMAIL PROTECTED] -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: tracking down suspend/hibernate bugs?
Matthew Garrett said the following on 01/15/2008 09:00 AM: > acpid needs restarting, so rebooting is the easiest way to do that. If > Fn+Esc no longer works, there's some sort of KDE issue. This is not good. I had a kernel update so had to reboot anyway. Now I find that even Fn-Esc does not work. The only way to suspend is by konsole with "sudo pm-suspend" and it still works ok. The kde-power-manager menu "suspend" does not work. either nor the keyboard "sleep" button. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: tracking down suspend/hibernate bugs?
On Tue, Jan 15, 2008 at 08:25:38AM -0500, Paul S wrote: > but same result .. /var/log/pm-suspend.log does not change, suspend / > resume work only from laptop Fn-Esc, not kde-power-manager menu or usb > keyboard sleep button and no "logger" message in /var/log/messages. > > Do I need to reboot after changing that file? If so, I did not. acpid needs restarting, so rebooting is the easiest way to do that. If Fn+Esc no longer works, there's some sort of KDE issue. -- Matthew Garrett | [EMAIL PROTECTED] -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: tracking down suspend/hibernate bugs?
Matthew Garrett said the following on 01/15/2008 07:12 AM: > On Mon, Jan 14, 2008 at 09:17:29PM -0500, Paul S wrote: > >> Since kde-power-manager won't work and my usb keyboard sleep button >> doesn't work, I tried the Fn-Esc key combo on the laptop, which is the >> suspend key combo. The laptop suspended and resumed fine. Now, when I >> look at /var/log/messages, there is no line from the logger that I >> inserted above. Also, when I look at /var/log/pm-suspend.log, it never >> changed from the previous suspend. So, it appears something else is >> functioning to suspend, other than pm-utils via hal. > > Yeah, something's clearly catching that. Can you try changing > /etc/acpi/events/sleepbtn to call sleepbtn.sh and not sleep.sh? > paul :/etc/acpi/events$ cat sleepbtn # /etc/acpi/events/sleepbtn # Called when the user presses the sleep button event=button[ /]sleep action=/etc/acpi/sleep.sh changed: paul :/etc/acpi/events$ sudo nano sleepbtn paul :/etc/acpi/events$ cat sleepbtn # /etc/acpi/events/sleepbtn # Called when the user presses the sleep button event=button[ /]sleep action=/etc/acpi/sleepbtn.sh but same result .. /var/log/pm-suspend.log does not change, suspend / resume work only from laptop Fn-Esc, not kde-power-manager menu or usb keyboard sleep button and no "logger" message in /var/log/messages. Do I need to reboot after changing that file? If so, I did not. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: tracking down suspend/hibernate bugs?
On Mon, Jan 14, 2008 at 09:17:29PM -0500, Paul S wrote: > Since kde-power-manager won't work and my usb keyboard sleep button > doesn't work, I tried the Fn-Esc key combo on the laptop, which is the > suspend key combo. The laptop suspended and resumed fine. Now, when I > look at /var/log/messages, there is no line from the logger that I > inserted above. Also, when I look at /var/log/pm-suspend.log, it never > changed from the previous suspend. So, it appears something else is > functioning to suspend, other than pm-utils via hal. Yeah, something's clearly catching that. Can you try changing /etc/acpi/events/sleepbtn to call sleepbtn.sh and not sleep.sh? -- Matthew Garrett | [EMAIL PROTECTED] -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: tracking down suspend/hibernate bugs?
On Mon, 2008-01-14 at 23:42 +, Matthew Garrett wrote: > On Mon, Jan 14, 2008 at 11:10:49AM -0800, Matt Price wrote: > > > sudo pm-suspend > > Right, so it sounds more like the issue here is that we're passing > quirks that are breaking your system. For reference, the quirks that are > used by default on Ubuntu are currently: > > --quirk-dpms-on > --quirk-vbestate-restore > --quirk-vbemode-restore > --quirk-vga-mode3 > --quirk-vbe-post > --quirk-reset-brightness > > If you pass those, does it fail? If so, can you try to figure out which > one is causing it? hmm. those all seem to work, so i guess the problem is somehow in the configuration of the gnome "log out button" on my system. quite possibly there's some cruft left over from long-ago attempts to make suspend work on this laptop back in the dark ages when nothing worked by default. so, probably the bug is of my own making. but matt, can you tell me what package owns those logout functions, and what the chain is that leads to a suspend cycle being enacted? I can commit to documenting all this somewhere inn the wiki so that others don't have the same befuddlement. but i'd also like to be able to use the gui buttons again, if only to stop my family members from guffawing about how user-unfriendly linux is. thanks again, matt > -- Matt Price [EMAIL PROTECTED] -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: tracking down suspend/hibernate bugs?
Paul S said the following on 01/14/2008 08:17 PM: > Still no idea why kde-power-manager can't start a suspend Here's an idea .. maybe some of the old acpi-support suspend is still active. I just tried adding a logger line to /usr/lib/hal/scripts/linux/hal-system-power-suspend-linux to print out the $QUIRKS: # We only support pm-utils if [ -x "/usr/sbin/pm-suspend" ] ; then logger "pm-suspend quirks are $QUIRKS" /usr/sbin/pm-suspend $QUIRKS RET=$? Since kde-power-manager won't work and my usb keyboard sleep button doesn't work, I tried the Fn-Esc key combo on the laptop, which is the suspend key combo. The laptop suspended and resumed fine. Now, when I look at /var/log/messages, there is no line from the logger that I inserted above. Also, when I look at /var/log/pm-suspend.log, it never changed from the previous suspend. So, it appears something else is functioning to suspend, other than pm-utils via hal. I did an upgrade from gutsy. Maybe my system still has something installed that it shouldn't. If you want, I could probably do a fresh install from hardy alpha 3 .. let me know if you think it's necessary. regards, -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: tracking down suspend/hibernate bugs?
Matthew Garrett said the following on 01/14/2008 06:42 PM: > On Mon, Jan 14, 2008 at 11:10:49AM -0800, Matt Price wrote: > >> sudo pm-suspend > > Right, so it sounds more like the issue here is that we're passing > quirks that are breaking your system. For reference, the quirks that are > used by default on Ubuntu are currently: > > --quirk-dpms-on > --quirk-vbestate-restore > --quirk-vbemode-restore > --quirk-vga-mode3 > --quirk-vbe-post > --quirk-reset-brightness > > If you pass those, does it fail? If so, can you try to figure out which > one is causing it? > I've tried this twice and it succeeded both times: paul :~$ sudo pm-suspend --quirk-dpms-on --quirk-vga-mode3 --quirk-reset-brightness --quirk-vbe-post --quirk-vbemode-restore --quirk-vbestate-restore I must admit I am surprised because I have an nvidia driver 169.07 and always thought it did not support use of vbetools. In fact the nvidia-glx-new README says: o Some distributions use a tool called vbetool to save and restore VGA adapter state. This tool is incompatible with NVIDIA GPUs' Video BIOSes and is likely to lead to problems restoring the GPU and its state. Disabling calls to this tool in your distribution's init scripts may improve power management reliability. But the proof is in the success. By the way, I don't see --quirk-reset-brightness in the pm-suspend man page??? Still no idea why kde-power-manager can't start a suspend -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: tracking down suspend/hibernate bugs?
On Mon, Jan 14, 2008 at 11:10:49AM -0800, Matt Price wrote: > sudo pm-suspend Right, so it sounds more like the issue here is that we're passing quirks that are breaking your system. For reference, the quirks that are used by default on Ubuntu are currently: --quirk-dpms-on --quirk-vbestate-restore --quirk-vbemode-restore --quirk-vga-mode3 --quirk-vbe-post --quirk-reset-brightness If you pass those, does it fail? If so, can you try to figure out which one is causing it? -- Matthew Garrett | [EMAIL PROTECTED] -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: tracking down suspend/hibernate bugs?
On Mon, Jan 14, 2008 at 10:30:33AM -0800, Matt Price wrote: > ... i suppose if the resume worked properly the reverse steps would be > present too? You'd hope so :) How exactly is the resume failing, and which graphics drivers are you using? > ah, this is my bad -- it seems an old script i had in > in /etc/acpi/lid-hibernate.sh was being called on lid closure; i thought > i'd verified that my old scripts had been replaced by the standard ones > on upgrade, but that one escaped my attention. that script calls > hibernate, which suspends & resumes successfully, while pm-utils appears > not to. Ah, interesting. Yes, that would explain the difference. I'll take a look at hibernate and see what it's doing by default (I haven't checked it out in some time). We are talking about suspend to RAM here, right? -- Matthew Garrett | [EMAIL PROTECTED] -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: tracking down suspend/hibernate bugs?
Matt Price said the following on 01/14/2008 02:10 PM: > hmmm... fooling around, i find that i can suspend pretty reliably from > the command line > > sudo pm-suspend > > but that the gnome-power-manager dialog reliably fails to resume; this > despitethe fact that it seemsto be using pm-suspend, as it writes a > suspend log to /var/log/pm-suspend. not sure what's going on there. maybe coincidence, but this sounds similar to my experience with kde-power-manager. Suspend / resume working from konsole with "sudo pm-suspend" , but not working from kde-power-manager menu or from logout -> suspend (using kdm, not gdm). But, here it's only with suspend, as hibernate works from kde-power-manager menu. I also notice that my sleep button on my usb keyboard no does not work on hardy (but did on gutsy). The other multimedia keys work ok on hardy as well as gutsy. Not sure why just the sleep quit. It calls suspend, not hibernate. So, with both operating systems not working, could it be the underlying hal system that's not functioning correctly? -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: tracking down suspend/hibernate bugs?
On Mon, 2008-01-14 at 10:30 -0800, Matt Price wrote: > On Mon, 2008-01-14 at 15:23 +, Matthew Garrett wrote: > > On Sun, Jan 13, 2008 at 10:51:48PM -0800, Matt Price wrote: > > > > > > i alsoseem to have an odd problem -- if i choose 'suspend' from the > > > gnome 'quit' menu, then resume fails. if, however, i suspend just by > > > closing the lid on my laptop, suspend and resume both succeed. this > > > suggests to me that two different methods are being used, probably acpi > > > in the lid case and pm-utils in the gnome case. seems to me this > > > shouldn't happen; again, i'm not quite sure what's going on. > > > > Both cases should be the same. I'll check to make sure that the logout > > dialog is triggering pm-utils, but lid closure should certainly be going > > through hal. hmmm... fooling around, i find that i can suspend pretty reliably from the command line sudo pm-suspend but that the gnome-power-manager dialog reliably fails to resume; this despitethe fact that it seemsto be using pm-suspend, as it writes a suspend log to /var/log/pm-suspend. not sure what's going on there. matt > > > -- > > Matthew Garrett | [EMAIL PROTECTED] > > > -- Matt Price [EMAIL PROTECTED] -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: tracking down suspend/hibernate bugs?
On Mon, 2008-01-14 at 15:23 +, Matthew Garrett wrote: > On Sun, Jan 13, 2008 at 10:51:48PM -0800, Matt Price wrote: > > > in hardy it appears that acpi-support has been cut out entirely in favor > > of pm-utils -- see the attached hal-system-power-suspend-linux script. > > i've flipped through the pm-utils code & can't see exactly how it's > > determined what is used to make the actual suspend call -- for instance, > > i'm not sure what I would do if i wanted to use a custom kernel with > > tuxonice for suspend, which i think still works best if it's called by > > the hibernate script. > > If it's triggered by writing disk to /sys/power/state (which I believe > it is, nowadays) then pm-hibernate will trigger it happily. Please don't > use the hibernate script - any cases where it works and pm-utils doesn't > are bugs that need fixing. > ok, i won't use it, but it appears that i have one of those cases -- see below. i'm still missing some of the flexibility & the extensive logging capabilities of hibernate. my /var/log/pm-suspend is very brief -- right now it reads: > Sun Jan 13 18:04:49 PST 2008: running hibernate hooks. > = Sun Jan 13 18:04:49 PST 2008: running hook: > /usr/lib/pm-utils/sleep.d/00clear = > = Sun Jan 13 18:04:49 PST 2008: running hook: > /usr/lib/pm-utils/sleep.d/05led = > = Sun Jan 13 18:04:49 PST 2008: running hook: > /usr/lib/pm-utils/sleep.d/10NetworkManager = > = Sun Jan 13 18:04:49 PST 2008: running hook: > /usr/lib/pm-utils/sleep.d/20video = > = Sun Jan 13 18:04:49 PST 2008: running hook: > /usr/lib/pm-utils/sleep.d/49bluetooth = > = Sun Jan 13 18:04:49 PST 2008: running hook: > /usr/lib/pm-utils/sleep.d/50modules = > = Sun Jan 13 18:04:49 PST 2008: running hook: > /usr/lib/pm-utils/sleep.d/90clock = > = Sun Jan 13 18:04:50 PST 2008: running hook: > /usr/lib/pm-utils/sleep.d/94cpufreq = > = Sun Jan 13 18:04:50 PST 2008: running hook: > /usr/lib/pm-utils/sleep.d/95led = > = Sun Jan 13 18:04:50 PST 2008: running hook: > /usr/lib/pm-utils/sleep.d/99video = > Sun Jan 13 18:04:50 PST 2008: done running hibernate hooks. ... i suppose if the resume worked properly the reverse steps would be present too? > > i alsoseem to have an odd problem -- if i choose 'suspend' from the > > gnome 'quit' menu, then resume fails. if, however, i suspend just by > > closing the lid on my laptop, suspend and resume both succeed. this > > suggests to me that two different methods are being used, probably acpi > > in the lid case and pm-utils in the gnome case. seems to me this > > shouldn't happen; again, i'm not quite sure what's going on. > > Both cases should be the same. I'll check to make sure that the logout > dialog is triggering pm-utils, but lid closure should certainly be going > through hal. > ah, this is my bad -- it seems an old script i had in in /etc/acpi/lid-hibernate.sh was being called on lid closure; i thought i'd verified that my old scripts had been replaced by the standard ones on upgrade, but that one escaped my attention. that script calls hibernate, which suspends & resumes successfully, while pm-utils appears not to. now the question is, what i should do to track down what is causing one process to work while the other fails. attached are my acpi lid hibernate script, and the various config files called in succession by the hibernate program. evolution doesn't seem to be letting me rename them, so i'll say that common.conf-mine is symlinked to /etc/hibernate/common.conf, which is eventually loaded by either sysfs-disk.conf or ususpend-ram.conf -- i'm not sure which method is actually executed at the moment. hibernate-short is my hibernate log from a single syspend-resume cycle. pls let me know whether this stuff helps. i'm hoping that i can set the value of $QUIRKS to match what's happening in hibernate & make pm-utils work just as well; but right now i'm not sure how to do that. > > apt cache gives this list as the ubuntu maintainer of pm-utils; the > > changelog suggests that the package has just been ported over unchanged > > from debian. if it's going to be the main power management tool, it > > seems like an important piece of infrastructure; is anyone at ubuntu > > watching over it at all? if so, please let me know what i can do to > > help with debugging and stuff. > > Yes, I'm looking after it. well, thanks for that & for responding so quickly. matt > -- > Matthew Garrett | [EMAIL PROTECTED] > lid-hibernate.sh Description: application/shellscript # This file is used when suspending to RAM. Use the *-ram.conf files to add # configuration options, or add them before the TryMethod lines in this file. # Options are not case-sensitive. # # See hibernate.conf(5) for help on the configuration items. # save to both, RAM and disk # (disabled by default, since it takes longer) # TryMethod ususpend-both.conf TryMethod ususpend-ram.conf TryMeth
Re: tracking down suspend/hibernate bugs?
On Mon, 2008-01-14 at 16:41 +, Matthew Garrett wrote: > Filing bugs is ok, but if you think an issue is generic then > feel free to bring it up here. Is suspend/hibernate with laptops using the new proprietary ATi driver (fglrx) in Hardy expected to work now, or is is still normal to fail? I'm not sure whether I shall file bugs for it. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: tracking down suspend/hibernate bugs?
On Mon, Jan 14, 2008 at 10:57:13AM -0500, Paul S wrote: > Are you the contact for these kubuntu issues as well as the ubuntu lead? No, I'm afraid I've got no experience of KDE at all. > Is it too early to start feedback on this stuff now, or should we > continue? Do you want us to feedback on this list or start bugs? Now is a fine time to provide feedback - there shouldn't be any major changes. Filing bugs is ok, but if you think an issue is generic then feel free to bring it up here. -- Matthew Garrett | [EMAIL PROTECTED] -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: tracking down suspend/hibernate bugs?
Matthew Garrett said the following on 01/14/2008 10:23 AM: >> watching over it at all? if so, please let me know what i can do to >> help with debugging and stuff. > > Yes, I'm looking after it. I also would like to see suspend and hibernate finally work, so I upgraded to hardy to try it too. I'm a kde user, so may have some different issues. For example, I can do "sudo pm-suspend" at the terminal and it works, but kde-power-manager does nothing when I select suspend from it's menu. Also, I notice some problem that may be related to artsd failing after 2nd and higher suspends, so I added a script to /etc/pm/sleep.d/ to stop and restart all sound programs and it seems to fix it, although I need more testing. But, I'm not a coder, so someone who is might fix it in artsd. Are you the contact for these kubuntu issues as well as the ubuntu lead? Is it too early to start feedback on this stuff now, or should we continue? Do you want us to feedback on this list or start bugs? regards, Paul -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: tracking down suspend/hibernate bugs?
On Sun, Jan 13, 2008 at 10:51:48PM -0800, Matt Price wrote: > in hardy it appears that acpi-support has been cut out entirely in favor > of pm-utils -- see the attached hal-system-power-suspend-linux script. > i've flipped through the pm-utils code & can't see exactly how it's > determined what is used to make the actual suspend call -- for instance, > i'm not sure what I would do if i wanted to use a custom kernel with > tuxonice for suspend, which i think still works best if it's called by > the hibernate script. If it's triggered by writing disk to /sys/power/state (which I believe it is, nowadays) then pm-hibernate will trigger it happily. Please don't use the hibernate script - any cases where it works and pm-utils doesn't are bugs that need fixing. > i alsoseem to have an odd problem -- if i choose 'suspend' from the > gnome 'quit' menu, then resume fails. if, however, i suspend just by > closing the lid on my laptop, suspend and resume both succeed. this > suggests to me that two different methods are being used, probably acpi > in the lid case and pm-utils in the gnome case. seems to me this > shouldn't happen; again, i'm not quite sure what's going on. Both cases should be the same. I'll check to make sure that the logout dialog is triggering pm-utils, but lid closure should certainly be going through hal. > apt cache gives this list as the ubuntu maintainer of pm-utils; the > changelog suggests that the package has just been ported over unchanged > from debian. if it's going to be the main power management tool, it > seems like an important piece of infrastructure; is anyone at ubuntu > watching over it at all? if so, please let me know what i can do to > help with debugging and stuff. Yes, I'm looking after it. -- Matthew Garrett | [EMAIL PROTECTED] -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: tracking down suspend/hibernate bugs?
On Sun, 2008-01-13 at 21:51 -0600, Aren Olson wrote: > In gutsy I believe the chain is this: > > gnome-power-manager -> hal > (/usr/lib/hal/scripts/hal-system-power-suspend) -> acpi-support > (/etc/acpi/sleep.sh) > most of the actual work occurs in acpi-support. > > hal may call a different tool than acpi-support if it is available > though, see /usr/lib/hal/scripts/linux/hal-system-power-suspend-linux > for full details. > in hardy it appears that acpi-support has been cut out entirely in favor of pm-utils -- see the attached hal-system-power-suspend-linux script. i've flipped through the pm-utils code & can't see exactly how it's determined what is used to make the actual suspend call -- for instance, i'm not sure what I would do if i wanted to use a custom kernel with tuxonice for suspend, which i think still works best if it's called by the hibernate script. i alsoseem to have an odd problem -- if i choose 'suspend' from the gnome 'quit' menu, then resume fails. if, however, i suspend just by closing the lid on my laptop, suspend and resume both succeed. this suggests to me that two different methods are being used, probably acpi in the lid case and pm-utils in the gnome case. seems to me this shouldn't happen; again, i'm not quite sure what's going on. apt cache gives this list as the ubuntu maintainer of pm-utils; the changelog suggests that the package has just been ported over unchanged from debian. if it's going to be the main power management tool, it seems like an important piece of infrastructure; is anyone at ubuntu watching over it at all? if so, please let me know what i can do to help with debugging and stuff. thanks as always, matt > Aren Olson > > On Jan 13, 2008 7:42 PM, Matt Price <[EMAIL PROTECTED]> wrote: > > hi, > > > > just upgraded to hardy and suspend-to-ram is broken again (as in feisty > > & other releases) i'm trying to figure out, again, how to track down > > this bug but i'm not entirely sure what the current chain of events is > > in the suspend process. can someone point me to a location where the > > process is described? or suggest best practice for finding bugs of this > > nature (in which resume is impossible, so messages e.g. from dmesg > > or /var/log/messages don't get captured? > > > > thanks, > > > > matt > > > > > > > > -- > > Matt Price > > [EMAIL PROTECTED] > > > > -- > > Ubuntu-devel-discuss mailing list > > Ubuntu-devel-discuss@lists.ubuntu.com > > Modify settings or unsubscribe at: > > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss > > > > > -- Matt Price [EMAIL PROTECTED] hal-system-power-suspend-linux Description: application/shellscript -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: tracking down suspend/hibernate bugs?
In gutsy I believe the chain is this: gnome-power-manager -> hal (/usr/lib/hal/scripts/hal-system-power-suspend) -> acpi-support (/etc/acpi/sleep.sh) most of the actual work occurs in acpi-support. hal may call a different tool than acpi-support if it is available though, see /usr/lib/hal/scripts/linux/hal-system-power-suspend-linux for full details. Aren Olson On Jan 13, 2008 7:42 PM, Matt Price <[EMAIL PROTECTED]> wrote: > hi, > > just upgraded to hardy and suspend-to-ram is broken again (as in feisty > & other releases) i'm trying to figure out, again, how to track down > this bug but i'm not entirely sure what the current chain of events is > in the suspend process. can someone point me to a location where the > process is described? or suggest best practice for finding bugs of this > nature (in which resume is impossible, so messages e.g. from dmesg > or /var/log/messages don't get captured? > > thanks, > > matt > > > > -- > Matt Price > [EMAIL PROTECTED] > > -- > Ubuntu-devel-discuss mailing list > Ubuntu-devel-discuss@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss > -- "Whoever said sunshine brings happiness has never danced in the rain." - K. Jackson Ubuntu Linux - www.ubuntu.com -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
