On Fedora 22 cleanly installed, this is what I see in Settings > Power:
Automatic suspend: Off When battery power is critical: Hibernate
There are no choices, those are fixed settings that I can't change. The actual behavior I see when the battery gets critical though, is suspend, not hibernate. First there is a message the machine is about to be hibernated, but then:
Sep 27 02:45:38 f22m.localdomain systemd-sleep[4960]: Suspending system...
I get the same results with Fedora 23, with one exception in Settings
Power "When battery power is critical: Hibernate" is not listed at
all, just that automatic suspend is off.
Anyway, the system suspends, but there is no battery power so the suspend to RAM is lost, and it's entirely possible if not likely that there will be data loss or fs corruption as a result.
Also cc'ing test@ because I'm not seeing a test case for this. It seems to me that out of the box we shouldn't be risking people's data like this, but it's not like poweroff -f is a whole lot better (except for the fs portion).
hi I'm no expert, but I remember seeing entries in gnome shell's commit log to the effect that the "when battery power is critical" settings were removed in gnome 3.18 because the ability to configure them was removed in upower > 1.0. Seems counterintuitive to me but shrug, what do I know. You should definitely be able to change the autosuspend settings. Just press enter on the item and a menu should appear with buttons. If your laptop has a battery, you'll see "autosuspend when plugged in" and "autosuspend when on battery power" buttons with time increments when clicked on. Thanks Kendell clark
On 09/27/2015 07:59 PM, Chris Murphy wrote:
On Fedora 22 cleanly installed, this is what I see in Settings > Power:
Automatic suspend: Off When battery power is critical: Hibernate
There are no choices, those are fixed settings that I can't change. The actual behavior I see when the battery gets critical though, is suspend, not hibernate. First there is a message the machine is about to be hibernated, but then:
Sep 27 02:45:38 f22m.localdomain systemd-sleep[4960]: Suspending system...
I get the same results with Fedora 23, with one exception in Settings
Power "When battery power is critical: Hibernate" is not listed at
all, just that automatic suspend is off.
Anyway, the system suspends, but there is no battery power so the suspend to RAM is lost, and it's entirely possible if not likely that there will be data loss or fs corruption as a result.
Also cc'ing test@ because I'm not seeing a test case for this. It seems to me that out of the box we shouldn't be risking people's data like this, but it's not like poweroff -f is a whole lot better (except for the fs portion).
On Sun, Sep 27, 2015 at 7:42 PM, kendell clark coffeekingms@gmail.com wrote:
You should definitely be able to change the autosuspend settings. Just press enter on the item and a menu should appear with buttons.
I can, it's just that there's an incongruence among the default setting (off), the notification I get (it will hibernate), and what actually happens (sleep/suspend to RAM).
For a 1% battery state to result in anything other than power off or hibernate (suspend to disk) seems like a bad idea. And since hibernation is variably broken, that's probably not a good option. https://bugzilla.redhat.com/show_bug.cgi?id=1206912
Like I mention in the bug, hibernation depends significantly on the firmware on today's hardware. But on Linux it depends on booting normally, and the kernel discovering the hibernation image, but I've never seen this work on any EFI Mac systems I've tried this on: the kernel claims to look for a hibernation image but doesn't find it. This happens whether resume= is set on the kernel command line or not. On BIOS it resumes only if resume= is on the kernel command line even though this supposedly is handled by initramfs, but anaconda doesn't include any hibernation support (neither the resume= nor does it create a sufficiently large swap partition).
And then there are the IRST supporting laptops, and while there's some kernel support for this I don't know if systemd or GNOME will leverage it. The RAM to disk dump is definitely always unencrypted though.
Just a refresher that hibernation support in the kernel is somewhere between deprecated and in abeyance. https://bugzilla.redhat.com/show_bug.cgi?id=781749
----- Original Message -----
On Sun, Sep 27, 2015 at 7:42 PM, kendell clark coffeekingms@gmail.com wrote:
You should definitely be able to change the autosuspend settings. Just press enter on the item and a menu should appear with buttons.
I can, it's just that there's an incongruence among the default setting (off), the notification I get (it will hibernate), and what actually happens (sleep/suspend to RAM).
Then there's a bug in UPower or systemd.
For a 1% battery state to result in anything other than power off or hibernate (suspend to disk) seems like a bad idea.
Hibernate is the default if it's supported. You can check with: upower -d | grep critical-action
And since hibernation is variably broken, that's probably not a good option. https://bugzilla.redhat.com/show_bug.cgi?id=1206912
Like I mention in the bug, hibernation depends significantly on the firmware on today's hardware. But on Linux it depends on booting normally, and the kernel discovering the hibernation image, but I've never seen this work on any EFI Mac systems I've tried this on: the kernel claims to look for a hibernation image but doesn't find it. This happens whether resume= is set on the kernel command line or not. On BIOS it resumes only if resume= is on the kernel command line even though this supposedly is handled by initramfs, but anaconda doesn't include any hibernation support (neither the resume= nor does it create a sufficiently large swap partition).
And then there are the IRST supporting laptops, and while there's some kernel support for this I don't know if systemd or GNOME will leverage it. The RAM to disk dump is definitely always unencrypted though.
Nobody added support for IRST as a new kernel sleep state, so the support in systemd isn't finished.
*BUT*. Suspending on a machine which supports that mode should be migrated to disk by the firmware. Right now, given the kernel's support for IRST, we can't show the difference between a firmware hibernation and suspend.
Cheers
On Wed, Oct 7, 2015 at 2:49 AM, Bastien Nocera bnocera@redhat.com wrote:
Chris Murphy wrote:
I can, it's just that there's an incongruence among the default setting (off), the notification I get (it will hibernate), and what actually happens (sleep/suspend to RAM).
Then there's a bug in UPower or systemd.
Any suggestion on isolating which one and then I can file a bug?
For a 1% battery state to result in anything other than power off or hibernate (suspend to disk) seems like a bad idea.
Hibernate is the default if it's supported. You can check with: upower -d | grep critical-action
HybridSleep
Seems like hibernate by default isn't appropriate by default since the installer doesn't support setting up swap for hibernate.
And then there are the IRST supporting laptops, and while there's some kernel support for this I don't know if systemd or GNOME will leverage it. The RAM to disk dump is definitely always unencrypted though.
Nobody added support for IRST as a new kernel sleep state, so the support in systemd isn't finished.
So this is insufficient? https://lkml.org/lkml/2013/7/2/544
*BUT*. Suspending on a machine which supports that mode should be migrated to disk by the firmware. Right now, given the kernel's support for IRST, we can't show the difference between a firmware hibernation and suspend.
Or presumably configure whether to use it, although I don't really see much of a downside to just always using this feature if it's available. Maybe one is that it requires its own partition, with the IRST partition type GUID set. It can't use the Linux swap partition. So that means doubling up on extra partitions.
----- Original Message -----
On Wed, Oct 7, 2015 at 2:49 AM, Bastien Nocera bnocera@redhat.com wrote:
Chris Murphy wrote:
I can, it's just that there's an incongruence among the default setting (off), the notification I get (it will hibernate), and what actually happens (sleep/suspend to RAM).
Then there's a bug in UPower or systemd.
Any suggestion on isolating which one and then I can file a bug?
As root: killall -9 upowerd /usr/libexec/upowerd -v
and check the logs after reproducing the problem.
For a 1% battery state to result in anything other than power off or hibernate (suspend to disk) seems like a bad idea.
Hibernate is the default if it's supported. You can check with: upower -d | grep critical-action
HybridSleep
Seems like hibernate by default isn't appropriate by default since the installer doesn't support setting up swap for hibernate.
Sorry, HybridSleep is the default, and we'll ask logind if it's supported, and fallback. From /etc/UPower/UPower.conf:
# If HybridSleep isn't available, Hibernate will be used # If Hibernate isn't available, PowerOff will be used CriticalPowerAction=HybridSleep
And then there are the IRST supporting laptops, and while there's some kernel support for this I don't know if systemd or GNOME will leverage it. The RAM to disk dump is definitely always unencrypted though.
Nobody added support for IRST as a new kernel sleep state, so the support in systemd isn't finished.
So this is insufficient? https://lkml.org/lkml/2013/7/2/544
This doesn't integrate in the power subsystem of the kernel. This was my attempt to integrate it in systemd, but I was told it should be implemented in the kernel proper: http://lists.freedesktop.org/archives/systemd-devel/2013-October/013653.html
*BUT*. Suspending on a machine which supports that mode should be migrated to disk by the firmware. Right now, given the kernel's support for IRST, we can't show the difference between a firmware hibernation and suspend.
Or presumably configure whether to use it, although I don't really see much of a downside to just always using this feature if it's available. Maybe one is that it requires its own partition, with the IRST partition type GUID set. It can't use the Linux swap partition. So that means doubling up on extra partitions.
It will be used automatically *by the firmware* if you set it up that way.
Cheers
desktop@lists.fedoraproject.org
-
Bastien Nocera -
Chris Murphy -
kendell clark