1:41 p.m.
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
3:52 p.m.
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...
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
4:06 p.m.
On Wed, Apr 6, 2011 at 10:52 PM, Adam Williamson <awilliam(a)redhat.com>wrote:
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
4:22 p.m.
Fabian A. Scherschel (fab(a)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
4:29 p.m.
On 04/06/2011 04:22 PM, Bill Nottingham wrote:
Fabian A. Scherschel (fab(a)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".
--
-- Steve
9:30 p.m.
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.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
5:27 a.m.
How can I choose hibernate if it isn't exposed?
Fab
On Wed, Apr 6, 2011 at 11:22 PM, Bill Nottingham <notting(a)redhat.com> wrote:
Fabian A. Scherschel (fab(a)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(a)lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
6:34 a.m.
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(a)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(a)lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
6:47 a.m.
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
9:59 a.m.
On Thu, Apr 7, 2011 at 1:47 PM, Rahul Sundaram <metherid(a)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
5:06 p.m.
On Wed, Apr 6, 2011 at 1:52 PM, Adam Williamson <awilliam(a)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(a)lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
9:31 p.m.
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).
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
10:42 a.m.
On Wed, Apr 6, 2011 at 7:31 PM, Adam Williamson <awilliam(a)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(a)lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
5:22 p.m.
<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
5:56 p.m.
2011/4/6 "Jóhann B. Guðmundsson" <johannbg(a)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(a)lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
6:30 p.m.
On 04/06/2011 10:56 PM, Michael Knepher wrote:
2011/4/6 "Jóhann B.
Guðmundsson"<johannbg(a)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
7:30 p.m.
2011/4/6 "Jóhann B. Guðmundsson" <johannbg(a)gmail.com>:
On 04/06/2011 10:56 PM, Michael Knepher wrote:
> 2011/4/6 "Jóhann B. Guðmundsson"<johannbg(a)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(a)lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
4828
days inactive
4829
days old
18 comments
7 participants
participants (7)
-
Adam Williamson -
Bill Nottingham -
Fabian A. Scherschel -
Jóhann B. Guðmundsson -
Michael Knepher -
Rahul Sundaram -
SternData