I've tried following the debate over the change to suspend as the visible and default way of managing power, but have not been able to find any resolution of whether the default is expected to remain so on systems that do not either suspend or resume properly or if this is up to the distributions to handle.
My understanding is that gnome 3 default is to suspend, then hibernate after a certain period of time. While I don't think this is necessarily the wrong choice, it currently does not work on my laptop, which does not fully resume after a suspend, and for which hibernate is completely broken. Now, with gnome-tweak-tool, I can at least change the settings for closing the lid, but when I want to power off from the user menu, I still need to press Alt to get that option.
Will Fedora 15 attempt to recognize systems that are known not to support the default behavior? And/or is there a way (through gsettings I guess it would be?) for users to change this so we don't have to press Alt every time?
Michael Knepher
On Wed, 2011-04-06 at 11:41 -0700, Michael Knepher wrote:
I've tried following the debate over the change to suspend as the visible and default way of managing power, but have not been able to find any resolution of whether the default is expected to remain so on systems that do not either suspend or resume properly or if this is up to the distributions to handle.
Neither, really: it's the default, and if it doesn't work, the idea is that we fix that (the failure to suspend). Both GNOME and Fedora are not big fans of giant manually-updated blacklists due to previous experience.
My understanding is that gnome 3 default is to suspend, then hibernate after a certain period of time.
I don't think it does this (hybrid suspend), it just suspends.
While I don't think this is necessarily the wrong choice, it currently does not work on my laptop, which does not fully resume after a suspend, and for which hibernate is completely broken. Now, with gnome-tweak-tool, I can at least change the settings for closing the lid, but when I want to power off from the user menu, I still need to press Alt to get that option.
Will Fedora 15 attempt to recognize systems that are known not to support the default behavior?
AFAIK no, that would require a big ugly blacklist and manpower to maintain it. Is there a bug filed on the failure to suspend correctly?
And/or is there a way (through gsettings I guess it would be?) for users to change this so we don't have to press Alt every time?
Not sure about this...
On Wed, Apr 6, 2011 at 10:52 PM, Adam Williamson awilliam@redhat.comwrote:
I don't think it does this (hybrid suspend), it just suspends.
So we are knowingly risking people's laptops just running out of battery in a bag somewhere and their systems dying with possible data loss? As the default?
Fab
Fabian A. Scherschel (fab@sixgun.org) said:
I don't think it does this (hybrid suspend), it just suspends.
So we are knowingly risking people's laptops just running out of battery in a bag somewhere and their systems dying with possible data loss? As the default?
Hybrid suspend has never really been supported. You certainly can choose to hibernate instead of suspend-to-RAM.
Bill
On 04/06/2011 04:22 PM, Bill Nottingham wrote:
Fabian A. Scherschel (fab@sixgun.org) said:
I don't think it does this (hybrid suspend), it just suspends.
So we are knowingly risking people's laptops just running out of battery in a bag somewhere and their systems dying with possible data loss? As the default?
Hybrid suspend has never really been supported. You certainly can choose to hibernate instead of suspend-to-RAM.
Bill
My worry with hybrid suspend is that the disks will spin up at exactly the wrong time, when I'm banging my bag around, and damage the hardware. I generally think about suspending vs. hibernation vs. power off before putting the computer away.
I'd like to see all available options when I press ALT instead of just shifting from "suspend" to "shutdown".
On Wed, 2011-04-06 at 16:29 -0500, Steven Stern wrote:
I'd like to see all available options when I press ALT instead of just shifting from "suspend" to "shutdown".
Power Off gives you Restart as an option, now, but Hibernate isn't exposed anyway.
How can I choose hibernate if it isn't exposed?
Fab
On Wed, Apr 6, 2011 at 11:22 PM, Bill Nottingham notting@redhat.com wrote:
Fabian A. Scherschel (fab@sixgun.org) said:
I don't think it does this (hybrid suspend), it just suspends.
So we are knowingly risking people's laptops just running out of battery
in
a bag somewhere and their systems dying with possible data loss? As the default?
Hybrid suspend has never really been supported. You certainly can choose to hibernate instead of suspend-to-RAM.
Bill
test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Yes, I know that. What I mean is we don't give end users that option. They want a button on the menu, otherwise they won't use it.
Fab
On Thu, Apr 7, 2011 at 12:52 PM, Rahul Sundaram metherid@gmail.com wrote:
On 04/07/2011 03:57 PM, Fabian A. Scherschel wrote:
How can I choose hibernate if it isn't exposed?
The power settings in the control allow you to hibernate when the power is critically low. If you want to tweak it in other use cases, use gnome-tweak-tool.
Rahul
test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
On 04/07/2011 05:04 PM, Fabian A. Scherschel wrote:
Yes, I know that. What I mean is we don't give end users that option. They want a button on the menu, otherwise they won't use it.
Fab
I can't speak for all users but GNOME Tweak Tool does expose the option and it can be used by end users just fine if they really want hibernate. To my understanding, suspend/resume gets a lot more testing than hibernate does and I wouldn't advocate exposing it as a setting in the control panel at this point
Rahul
On Thu, Apr 7, 2011 at 1:47 PM, Rahul Sundaram metherid@gmail.com wrote:
I can't speak for all users but GNOME Tweak Tool does expose the option and it can be used by end users just fine if they really want hibernate. To my understanding, suspend/resume gets a lot more testing than hibernate does and I wouldn't advocate exposing it as a setting in the control panel at this point
Thanks very much for the clarification! :)
Fab
On Wed, Apr 6, 2011 at 1:52 PM, Adam Williamson awilliam@redhat.com wrote:
On Wed, 2011-04-06 at 11:41 -0700, Michael Knepher wrote:
I've tried following the debate over the change to suspend as the visible and default way of managing power, but have not been able to find any resolution of whether the default is expected to remain so on systems that do not either suspend or resume properly or if this is up to the distributions to handle.
Neither, really: it's the default, and if it doesn't work, the idea is that we fix that (the failure to suspend). Both GNOME and Fedora are not big fans of giant manually-updated blacklists due to previous experience.
I can certainly understand that.
My understanding is that gnome 3 default is to suspend, then hibernate after a certain period of time.
I don't think it does this (hybrid suspend), it just suspends.
A bit more googling, and all I found was a blog post referring to a #gnome-shell IRC conversation from late February, reporting that devs wanted to suspend, then wake up after 30 minutes and suspend-to-disk. Can't find any other references.
AFAIK no, that would require a big ugly blacklist and manpower to maintain it. Is there a bug filed on the failure to suspend correctly?
https://bugzilla.redhat.com/show_bug.cgi?id=690648 The issue with my laptop is that it appears to suspend properly, but the screen will not power back on when trying to resume. Everything else seems to work OK (had headphones plugged in, and banshee resumed the track it had been playing when it suspended). I filed it under pm-utils because I was testing it out around the time of the test day, but didn't have time to run a full test suite. Is there a better component for it? Hibernation is a whole other kettle of fish, and I have not had time to do a bug report on it yet.
And/or is there a way (through gsettings I guess it would be?) for users to change this so we don't have to press Alt every time?
Not sure about this...
Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net
-- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
On Wed, 2011-04-06 at 15:06 -0700, Michael Knepher wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=690648 The issue with my laptop is that it appears to suspend properly, but the screen will not power back on when trying to resume. Everything else seems to work OK (had headphones plugged in, and banshee resumed the track it had been playing when it suspended). I filed it under pm-utils because I was testing it out around the time of the test day, but didn't have time to run a full test suite. Is there a better component for it? Hibernation is a whole other kettle of fish, and I have not had time to do a bug report on it yet.
It's likely in the kernel or the graphics driver (which may actually mean also the kernel, but different developers). I'd switch it to kernel or xorg-x11-drv-(whatever'sappropriateforyourgraphicscard).
On Wed, Apr 6, 2011 at 7:31 PM, Adam Williamson awilliam@redhat.com wrote:
On Wed, 2011-04-06 at 15:06 -0700, Michael Knepher wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=690648 The issue with my laptop is that it appears to suspend properly, but the screen will not power back on when trying to resume. Everything else seems to work OK (had headphones plugged in, and banshee resumed the track it had been playing when it suspended). I filed it under pm-utils because I was testing it out around the time of the test day, but didn't have time to run a full test suite. Is there a better component for it? Hibernation is a whole other kettle of fish, and I have not had time to do a bug report on it yet.
It's likely in the kernel or the graphics driver (which may actually mean also the kernel, but different developers). I'd switch it to kernel or xorg-x11-drv-(whatever'sappropriateforyourgraphicscard).
I tried switching the component, but it won't allow me.
-- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net
-- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
<snip>
All suspend resume bugs should be fixed hence if it fails for you or anyother reporter for that matter you should report it so please file a bug and attach /var/log/messages ,/var/log/pm-suspend.log and the file from su -c 'pm-utils-bugreport-info.sh > pm-utils-bugreport.txt'
You can test suspend from the graphical.target and multi-user.target by running
su -c 'pm-suspend'
and
su -c 'echo mem > /sys/power/state'
If the above fails in multi-user.target it's most likely is a kernel bug thus needs more advanced debugging.
JBG
2011/4/6 "Jóhann B. Guðmundsson" johannbg@gmail.com:
<snip>
All suspend resume bugs should be fixed hence if it fails for you or anyother reporter for that matter you should report it so please file a bug and attach /var/log/messages ,/var/log/pm-suspend.log and the file from su -c 'pm-utils-bugreport-info.sh > pm-utils-bugreport.txt'
You can test suspend from the graphical.target and multi-user.target by running
su -c 'pm-suspend'
and
su -c 'echo mem > /sys/power/state'
Am I supposed to run both or either of these commands? I ran the first, with the same results (no screen), and after restarting the system, attached the requested files to https://bugzilla.redhat.com/show_bug.cgi?id=690648
If the above fails in multi-user.target it's most likely is a kernel bug thus needs more advanced debugging.
JBG
test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
On 04/06/2011 10:56 PM, Michael Knepher wrote:
2011/4/6 "Jóhann B. Guðmundsson"johannbg@gmail.com:
<snip>
All suspend resume bugs should be fixed hence if it fails for you or anyother reporter for that matter you should report it so please file a bug and attach /var/log/messages ,/var/log/pm-suspend.log and the file from su -c 'pm-utils-bugreport-info.sh> pm-utils-bugreport.txt'
You can test suspend from the graphical.target and multi-user.target by running
su -c 'pm-suspend'
and
su -c 'echo mem> /sys/power/state'
Am I supposed to run both or either of these commands? I ran the first, with the same results (no screen), and after restarting the system, attached the requested files to https://bugzilla.redhat.com/show_bug.cgi?id=690648
What happens if you add pci=noacpi to the kernel command line and try to suspend/resume?
you should also add the output from dmesg to that bug report ( su -c 'dmesg > dmesg.txt' ) given that this mostlikely is a kernel bug
JBG
2011/4/6 "Jóhann B. Guðmundsson" johannbg@gmail.com:
On 04/06/2011 10:56 PM, Michael Knepher wrote:
2011/4/6 "Jóhann B. Guðmundsson"johannbg@gmail.com:
<snip>
All suspend resume bugs should be fixed hence if it fails for you or anyother reporter for that matter you should report it so please file a bug and attach /var/log/messages ,/var/log/pm-suspend.log and the file from su -c 'pm-utils-bugreport-info.sh> pm-utils-bugreport.txt'
You can test suspend from the graphical.target and multi-user.target by running
su -c 'pm-suspend'
and
su -c 'echo mem> /sys/power/state'
Am I supposed to run both or either of these commands? I ran the first, with the same results (no screen), and after restarting the system, attached the requested files to https://bugzilla.redhat.com/show_bug.cgi?id=690648
What happens if you add pci=noacpi to the kernel command line and try to suspend/resume?
After a normal boot, and logging in, and waiting for 5 minutes, I just had the background and a cursor and a network connection (I have synergy autostarting in my session). No top panel, no overlay. I killed the session with ctrl+alt+backspace and logged into a clean test user, which brought up the overlay after about 20 seconds, but nothing sensitive to user interaction other than cursor movement, and no user name in the user menu, and no network connection. So I was never able to get to a point within a user session at which I could suspend. I restarted with pci=noacpi and tried running suspend from gdm. Same apparent outcome.
you should also add the output from dmesg to that bug report ( su -c 'dmesg > dmesg.txt' ) given that this mostlikely is a kernel bug
Done. Would dmesg output following a boot with pci=noacpi appended be useful as well?
JBG
test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test