Re: 4% battery; dpesn't suspend
Huh. So when hybrid suspend+hibernate happened, I had a randomly encrypted swap setup. So this obviously can't ever be recovered from, because the key is lost. Well, actually the key is in the image on encrypted swap. So the only copy of the key is encrypted. Ha. Anyway, after setting up an ordinary plain partition swap, updating fstab, and adding resume=UUID= boot param; plain hibernate with 'sudo systemctl hibernate' enters and exits hibernation normally even though Secure Boot is enabled. So something has changed. I've asked on the kernel list. I haven't tested hybrid sleep again yet, so I'm still not sure what that immediate wake up is all about. Anyone looking to get more info about this should add the 'no_console_suspend' boot param. It might help give an idea what's going on, but there's also some chance this ends up relating to ACPI (a very deep dark rabbit hole). --- Chris Murphy ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org/message/4VVRN6B3GODX35RUG6DDLJIQNVDICCUH/
Re: 4% battery; dpesn't suspend
OK so I've run into this also on Fedora 28. (This is with the "sick" battery that Windows says is OK, and HP's battery checker says is OK. And yet at 18% battery and 45 minutes remaining it goes into "hibernation"). So what Fedora is doing is hybrid sleep. Jun 02 15:11:33 f28h.local systemd[1]: Starting Hybrid Suspend+Hibernate... It is really super easy to be less than precise with language when it comes to power management, it's really complicated mostly because the various strategies keep changing by hardware manufacturers and Microsoft. So pretty much just accept that the only people who really grok this are the very serious amateurs, and devs whose expertise this is. And I'm neither, so you can take this with a grain of salt. My understanding of hybrid sleep, is that the kernel will freeze the memory state, write that image to the drive, and then go to suspend-to-RAM (S3) mode. That way if you add power, you can immediately wake up and the written hibernation image can just be ignored. But if you don't add power, and the battery goes below a certain point that suspend collapses into poweroff, the system state is in the hibernation image. The gotcha, at least for my system, is this should not happen because it's UEFI with Secure Boot enabled. I asked the kernel team fairly recently (about a year) and hibernation is not supported. A non-encrypted hibernation image is an injection point to side step the protection offered by Secure Boot. SUSE has a patch to do this, but we aren't using it, and mainline hasn't accepted any of that including a bunch of other Secure Boot related stuff - last I checked. So... bugger. And I'm experiencing the same effect where it immediately wakes up after it suspends following the writing of the hibernation image. But a non-hybrid suspend to RAM with laptop lid, or pressing power button quickly, or holding alt while clicking on the GNOME upper right hand menu power button (which with alt key has a pause symbol instead), all of those work. As for what checks logind does to know whether it can hibernate, it looks like RAM must not be more than 98% of swap. DE's that use Hibernate() bus call when RAM is bigger than free swap (that is, swap could be used for swap and for hibernation image, but typically you hope swap is little used or not used at all; but if a lot is used it can mean Hibernate() fails because there isn't enough room for swap and the hibernate image to be written in the available swap space and that's why to really support hibernation, we need these rather substantially larger swap partitions than we have now, just in case swap is used for swap - haha, get it?) Anyway, if the DE calls Hibernate() and it fails due to lack of space, it's up to the DE to decide what to fallback on. And I haven't tested any of that. So I don't know what happens. There is also CanHibernate() which just does a check, rather than an attempt. https://lists.freedesktop.org/archives/systemd-devel/2016-April/036330.html Anyway, there's a bug here I think. The unprompted write from suspend following the writing of the hibernation image is one bug. And the very fact the system is trying to hibernate sounds like another unless we now support hibernation - which quite frankly would surprise me a lot. Chris Murphy ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org/message/MQZO6DIANNLGML4GO43UDC3XHDXEJEI6/
Re: 4% battery; dpesn't suspend
Allegedly, on or about 31 May 2018, sent: >> The usual method of hibernating is to dump the memory into the swap >> partition. I do not know what will happen if your swap partition >> is smaller than your RAM, though. Wolfgang Pfeiffer: > 32 GB of RAM here, swap space is just ~16 GB: my guess is that as > long as the totally used memory (including buffers/cache) isn't > bigger than the swap partition, some hibernation image might be > written successfully ... not being sure, tho' ... I believe it can also use a swap file, so you can add one to a partition with space. However, when there's more than one swap, I think you need to set a kernel parameter for the system to look in the right place for its resuming data. > And swap space is rarely used here, IIRC .. Generally speaking, the same here. But when I had a system with less RAM, web browsers were terrible at wasting RAM. If you had enough tabs open, or hit a badly coded website, the system would start paging and never recover unless I managed to kill the web browser. Often I couldn't, because the system was so unresponsive you couldn't use the mouse or keyboard. -- [tim@localhost ~]$ uname -rsvp Linux 4.16.7-100.fc26.x86_64 #1 SMP Wed May 2 21:45:56 UTC 2018 x86_64 Boilerplate: All mail to my mailbox is automatically deleted. There is no point trying to privately email me, I only get to see the messages posted to the mailing list. Programmers who can't take criticisms shouldn't release software that's so crap it seriously pisses people off. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org/message/VSLZ3OUQYKAGHEEDKN5FQ34N3OQUT5ZD/
Re: 4% battery; dpesn't suspend
On Wed, May 30, 2018 at 10:15:51AM +0930, Tim via users wrote: > Allegedly, on or about 29 May 2018, Wolfgang Pfeiffer sent: > > The logs here are interesting anyways, and I'm still wondering where > > the system actually saved the image: in /tmp, or swap partition? > > The usual method of hibernating is to dump the memory into the swap > partition. I do not know what will happen if your swap partition is > smaller than your RAM, though. Thanks for letting me know. 32 GB of RAM here, swap space is just ~16 GB: my guess is that as long as the totally used memory (including buffers/cache) isn't bigger than the swap partition, some hibernation image might be written successfully ... not being sure, tho' ... And swap space is rarely used here, IIRC .. Wolfgang ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org/message/RS2RUKKIJBAY6RPVF2GMPH4OLP4HL2VV/
Re: 4% battery; dpesn't suspend
On Wed, May 30, 2018 at 08:44:36AM +0100, Dave Mitchell wrote: > On Tue, May 29, 2018 at 08:12:39PM +0200, Wolfgang Pfeiffer wrote: > > > > On Mon, May 28, 2018 at 10:38:58PM +0100, Dave Mitchell wrote: > > > On Tue, Apr 17, 2018 at 10:26:22PM +0200, Wolfgang Pfeiffer wrote: > > > OP here - my UPower settings are the same as yours, and when I found time > > > to risk my battery getting down to 2% (I only tried to 4% originally), it > > > did indeed hibernate. Although it then immediately resumed :-( > > > > Resumed meaning it really "woke up", without your intervention like > > pressing a key or so? If yes I'd check the journalctl logs, because > > that seems a little strange to me. > > Yep. I get a 'critical alert' notification on the screen at 2%, then > the screen goes dark, followed by several seconds of disk activity light > flashing, then the screen turns on again, and I'm back where I was. > All without user intervention. > > > I had a similar situation a few days ago: I ran down battery until > > very low down. When the battery level was in what the system probably > > saw as critical (45%, something like that), it started > > sleep-hibernating (whatever the mix of these modes means), with > > journalctl writing (excerpt): > > > > Starting Hybrid Suspend+Hibernate... > > > > and seconds later: > > PM: Hibernation image created > > Here's a stripped-down log: > > [ ... ] > May 28 22:23:31 robin kernel: ACPI: Low-level resume complete > May 28 22:23:31 robin kernel: ACPI: EC: EC started > May 28 22:23:31 robin kernel: PM: Restoring platform NVS memory > May 28 22:23:31 robin kernel: Enabling non-boot CPUs ... > May 28 22:23:31 robin kernel: x86: Booting SMP configuration: > May 28 22:23:31 robin kernel: smpboot: Booting Node 0 Processor 1 APIC 0x2 > May 28 22:23:31 robin kernel: cache: parent cpu1 should not be sleeping > May 28 22:23:31 robin kernel: CPU1 is up From these logs I cannot see why this did not work .. > NB - this laptop does a normal suspend/resume quite happily when closing > /opening lid. Same here: the only time this machine refuses to sleep (S3 sleep, different from the emergency hibernation from above, it seems) is when an external monitor is connected to the computer, via HDMI cable. You sure that there was nothing similar on your machine that might have prevented the emergency hibernate, by resuming immediately again? HTH Wolfgang ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org/message/PFAZWOCHSLICZ4PQDNHZEL3OLVE4FCAZ/
Re: 4% battery; dpesn't suspend
On Tue, May 29, 2018 at 08:12:39PM +0200, Wolfgang Pfeiffer wrote: > > On Mon, May 28, 2018 at 10:38:58PM +0100, Dave Mitchell wrote: > > On Tue, Apr 17, 2018 at 10:26:22PM +0200, Wolfgang Pfeiffer wrote: > > OP here - my UPower settings are the same as yours, and when I found time > > to risk my battery getting down to 2% (I only tried to 4% originally), it > > did indeed hibernate. Although it then immediately resumed :-( > > Resumed meaning it really "woke up", without your intervention like > pressing a key or so? If yes I'd check the journalctl logs, because > that seems a little strange to me. Yep. I get a 'critical alert' notification on the screen at 2%, then the screen goes dark, followed by several seconds of disk activity light flashing, then the screen turns on again, and I'm back where I was. All without user intervention. > I had a similar situation a few days ago: I ran down battery until > very low down. When the battery level was in what the system probably > saw as critical (45%, something like that), it started > sleep-hibernating (whatever the mix of these modes means), with > journalctl writing (excerpt): > > Starting Hybrid Suspend+Hibernate... > > and seconds later: > PM: Hibernation image created Here's a stripped-down log: May 28 22:23:16 robin systemd[1]: Starting Hybrid Suspend+Hibernate... May 28 22:23:16 robin systemd-sleep[18493]: Suspending system... May 28 22:23:16 robin kernel: PM: hibernation entry May 28 22:23:16 robin kernel: PM: Syncing filesystems ... May 28 22:23:16 robin kernel: PM: done. May 28 22:23:30 robin kernel: Freezing user space processes ... (elapsed 0.003 seconds) done. May 28 22:23:30 robin kernel: OOM killer disabled. May 28 22:23:30 robin kernel: PM: Marking nosave pages: [mem 0x-0x0fff] [...25 similar lines...] May 28 22:23:31 robin kernel: PM: Preallocating image memory... done (allocated 627744 pages) May 28 22:23:31 robin kernel: PM: Allocated 2510976 kbytes in 2.26 seconds (.05 MB/s) May 28 22:23:31 robin kernel: Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done. May 28 22:23:31 robin kernel: Suspending console(s) (use no_console_suspend to debug) May 28 22:23:31 robin kernel: ACPI: EC: interrupt blocked May 28 22:23:31 robin kernel: Disabling non-boot CPUs ... May 28 22:23:31 robin kernel: smpboot: CPU 1 is now offline May 28 22:23:31 robin kernel: smpboot: CPU 2 is now offline May 28 22:23:31 robin kernel: smpboot: CPU 3 is now offline May 28 22:23:31 robin kernel: smpboot: CPU 4 is now offline May 28 22:23:31 robin kernel: smpboot: CPU 5 is now offline May 28 22:23:31 robin kernel: smpboot: CPU 6 is now offline May 28 22:23:31 robin kernel: smpboot: CPU 7 is now offline May 28 22:23:31 robin kernel: PM: Creating hibernation image: May 28 22:23:31 robin kernel: PM: Need to copy 623696 pages May 28 22:23:31 robin kernel: PM: Normal pages needed: 623696 + 1024, available pages: 1443975 May 28 22:23:31 robin kernel: PM: Hibernation image created (623696 pages copied) May 28 22:23:31 robin kernel: Enabling non-boot CPUs ... May 28 22:23:31 robin kernel: x86: Booting SMP configuration: May 28 22:23:31 robin kernel: smpboot: Booting Node 0 Processor 1 APIC 0x2 May 28 22:23:31 robin kernel: cache: parent cpu1 should not be sleeping May 28 22:23:31 robin kernel: CPU1 is up [...] May 28 22:23:31 robin kernel: smpboot: Booting Node 0 Processor 7 APIC 0x7 May 28 22:23:31 robin kernel: cache: parent cpu7 should not be sleeping May 28 22:23:31 robin kernel: CPU7 is up May 28 22:23:31 robin kernel: ACPI: EC: interrupt unblocked May 28 22:23:31 robin kernel: ath: phy0: ASPM enabled: 0x42 May 28 22:23:31 robin kernel: ACPI: button: The lid device is not compliant to SW_LID. May 28 22:23:31 robin kernel: ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [... more ata... and image saving progress lines ...] May 28 22:23:31 robin kernel: PM: Image saving done May 28 22:23:31 robin kernel: PM: Wrote 2499660 kbytes in 4.12 seconds (606.71 MB/s) May 28 22:23:31 robin kernel: PM: S| May 28 22:23:31 robin kernel: Suspending console(s) (use no_console_suspend to debug) May 28 22:23:31 robin kernel: sd 0:0:0:0: [sda] Synchronizing SCSI cache May 28 22:23:31 robin kernel: sd 0:0:0:0: [sda] Stopping disk May 28 22:23:31 robin kernel: PM: suspend devices took 0.679 seconds May 28 22:23:31 robin kernel: ACPI: EC: interrupt blocked May 28 22:23:31 robin kernel: ACPI: Preparing to enter system sleep state S3 May 28 22:23:31 robin kernel: ACPI: EC: event blocked May 28 22:23:31 robin kernel: ACPI: EC: EC stopped May 28 22:23:31 robin kernel: PM: Saving platform NVS memory May 28 22:23:31 robin kernel: Disabling non-boot CPUs ... May 28 22:23:31 robin kernel: smpboot: CPU 1 is now offline May 28 22:23:31 robin kernel: smpboot: CPU 2 is now offline May 28 22:23:31 robin kernel: smpboot: CPU 3 is now offline May 28 22:23:31 robin kernel: smpboot: CPU 4 is now offline May 28 22:23:31 robin kernel: smpboot: CPU 5 is now of
Re: 4% battery; dpesn't suspend
Allegedly, on or about 29 May 2018, Wolfgang Pfeiffer sent: > The logs here are interesting anyways, and I'm still wondering where > the system actually saved the image: in /tmp, or swap partition? The usual method of hibernating is to dump the memory into the swap partition. I do not know what will happen if your swap partition is smaller than your RAM, though. -- [tim@localhost ~]$ uname -rsvp Linux 4.16.7-100.fc26.x86_64 #1 SMP Wed May 2 21:45:56 UTC 2018 x86_64 Boilerplate: All mail to my mailbox is automatically deleted. There is no point trying to privately email me, I only get to see the messages posted to the mailing list. If you don't understand how e-mail threading works, then follow the instructions given by those who do, and don't argue with them. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org/message/C342R4O6OYQMCPPF2TW7WTK3UJOWLEP7/
Re: 4% battery; dpesn't suspend
On Mon, May 28, 2018 at 10:38:58PM +0100, Dave Mitchell wrote: > On Tue, Apr 17, 2018 at 10:26:22PM +0200, Wolfgang Pfeiffer wrote: > > I'm getting curious about your settings, if that's not too intrusive: > > mine are, with comments removed: > > > > -> > > % grep -v '^#' /etc/UPower/UPower.conf > > > > [UPower] > > > > EnableWattsUpPro=false > > > > NoPollBatteries=false > > > > IgnoreLid=false > > > > UsePercentageForPolicy=true > > > > PercentageLow=10 > > PercentageCritical=3 > > PercentageAction=2 > > OP here - my UPower settings are the same as yours, and when I found time > to risk my battery getting down to 2% (I only tried to 4% originally), it > did indeed hibernate. Although it then immediately resumed :-( Resumed meaning it really "woke up", without your intervention like pressing a key or so? If yes I'd check the journalctl logs, because that seems a little strange to me. I had a similar situation a few days ago: I ran down battery until very low down. When the battery level was in what the system probably saw as critical (45%, something like that), it started sleep-hibernating (whatever the mix of these modes means), with journalctl writing (excerpt): Starting Hybrid Suspend+Hibernate... and seconds later: PM: Hibernation image created and only woke up after I pressed the power button, IIRC. > So I guess I now have a different issue. BIOS maybe? No idea: syslogs/journalctl might tell you what was going on: The logs here are interesting anyways, and I'm still wondering where the system actually saved the image: in /tmp, or swap partition? ... HTH Wolfgang ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org/message/LXYSKWJJTTMZ4MY5LF66EM5SRLGPYDJW/
Re: 4% battery; dpesn't suspend
On Tue, Apr 17, 2018 at 10:26:22PM +0200, Wolfgang Pfeiffer wrote: > On Tue, 17 Apr 2018 10:53:09 -0700 > Samuel Sieb wrote: > > > On 04/17/2018 04:55 AM, Wolfgang Pfeiffer wrote: > > >Trying 'upower -d' here results in the display of current power > > > settings ... > > > > So that's why mine works. The output includes this line: > > critical-action: HybridSleep > > > > I do wonder what starts it up. The service is disabled although the > > default is enabled and I didn't manually start it. > > I'm getting curious about your settings, if that's not too intrusive: > mine are, with comments removed: > > -> > % grep -v '^#' /etc/UPower/UPower.conf > > [UPower] > > EnableWattsUpPro=false > > NoPollBatteries=false > > IgnoreLid=false > > UsePercentageForPolicy=true > > PercentageLow=10 > PercentageCritical=3 > PercentageAction=2 OP here - my UPower settings are the same as yours, and when I found time to risk my battery getting down to 2% (I only tried to 4% originally), it did indeed hibernate. Although it then immediately resumed :-( So I guess I now have a different issue. BIOS maybe? -- If life gives you lemons, you'll probably develop a citric acid allergy. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org/message/6BNFHKT56O5ZQZSOOQZQWFTKU64W552T/
Re: 4% battery; dpesn't suspend
On Tue, 17 Apr 2018 22:26:22 +0200 Wolfgang Pfeiffer wrote: > And that looks really interesting: > https://www.kernel.org/doc/Documentation/admin-guide/pm/sleep-states.rst Forgot that one: https://www.kernel.org/doc/Documentation/power/swsusp.txt Sorry, Wolfgang ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org
Re: 4% battery; dpesn't suspend
On Tue, 17 Apr 2018 10:53:09 -0700
Samuel Sieb wrote:
> On 04/17/2018 04:55 AM, Wolfgang Pfeiffer wrote:
> >Trying 'upower -d' here results in the display of current power
> > settings ...
>
> So that's why mine works. The output includes this line:
> critical-action: HybridSleep
>
> I do wonder what starts it up. The service is disabled although the
> default is enabled and I didn't manually start it.
I'm getting curious about your settings, if that's not too intrusive:
mine are, with comments removed:
->
% grep -v '^#' /etc/UPower/UPower.conf
[UPower]
EnableWattsUpPro=false
NoPollBatteries=false
IgnoreLid=false
UsePercentageForPolicy=true
PercentageLow=10
PercentageCritical=3
PercentageAction=2
TimeLow=1200
TimeCritical=300
TimeAction=120
CriticalPowerAction=HybridSleep
<--
IIRC when the battery was 0 a few days ago, the battery LED (here: the
Power On/Off button) started blinking fast, but no sleep was started.
Weird ...
The documentation for upower seems technichally to be missing on F26 -
so I have to guess whether Time{Low,Critical,Action} values actually
mean minutes or seconds ...
Archlinux has some documentation:
https://wiki.archlinux.org/index.php/Power_management#Hybrid_sleep
And that looks really interesting:
https://www.kernel.org/doc/Documentation/admin-guide/pm/sleep-states.rst
This latter page - after a glance on it - seems to suggest that sleep
modes are organized by the kernel, via three files. Here, they look
like so:
--->
% cat /sys/power/mem_sleep
s2idle [deep]
% cat /sys/power/state
freeze mem disk
% cat /sys/power/disk
[platform] shutdown reboot suspend test_resume
<--
HTH,
Wolfgang
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Re: 4% battery; dpesn't suspend
On 04/17/2018 04:55 AM, Wolfgang Pfeiffer wrote: Trying 'upower -d' here results in the display of current power settings ... So that's why mine works. The output includes this line: critical-action: HybridSleep I do wonder what starts it up. The service is disabled although the default is enabled and I didn't manually start it. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org
Re: 4% battery; dpesn't suspend
On Mon, 16 Apr 2018 08:41:56 +0100 Dave Mitchell wrote: > F27. I ran a new laptop battery down to 4% (as claimed by gnome) and my > laptop didn't auto-suspend, nor hibernate. I'm not that familiar with power settings on Fedora (having F26 here). But a look at upower.service might be useful - mine is disabled: % systemctl status upower.service ● upower.service - Daemon for power management Loaded: loaded (/usr/lib/systemd/system/upower.service; disabled; vendor pres Active: active (running) since Tue 2018-04-17 03:11:58 CEST; 10h ago Docs: man:upowerd(8) Main PID: 2562 (upowerd) Tasks: 3 (limit: 4915) CGroup: /system.slice/upower.service └─2562 /usr/libexec/upowerd > > In settings / power, the only option for battery power these days seems to > be to automatically suspend after a set time period; not at a certain > battery level. > 'Suspend' doesn't seem to be supported as an action for low battery level on Gnome ... But here, on F26: in /etc/UPower/UPower.conf I have a config option to set action (again: no suspend) according to a battery percentage level. Excerpt: UsePercentageForPolicy=true # When UsePercentageForPolicy is true, the levels at which UPower will # consider the battery low, critical, or take action for the critical # battery level. # # This will also be used for batteries which don't have time information # such as that of peripherals. # # If any value is invalid, or not in descending order, the defaults # will be used. # # Defaults: # PercentageLow=10 # PercentageCritical=3 # PercentageAction=2 PercentageLow=10 PercentageCritical=3 PercentageAction=2 Trying 'upower -d' here results in the display of current power settings ... HTH, Wolfgang ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org
Re: 4% battery; dpesn't suspend
On 16/04/18 08:41, Dave Mitchell wrote: > F27. I ran a new laptop battery down to 4% (as claimed by gnome) and my > laptop didn't auto-suspend, nor hibernate. > > In settings / power, the only option for battery power these days seems to > be to automatically suspend after a set time period; not at a certain > battery level. > > So > > a) did I imagine it that earlier fedoras used to have this feature? > b) any way I can enable auto-suspect on low battery for F27? > > Take a look at an earlier question I asked, 'Power settings wrong or battery dying', particularly the answers from Robbi Nespu. Might help you ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org
Re: 4% battery; dpesn't suspend
On 04/16/2018 12:41 AM, Dave Mitchell wrote: F27. I ran a new laptop battery down to 4% (as claimed by gnome) and my laptop didn't auto-suspend, nor hibernate. I was very surprised a few days ago when I left my laptop unplugged and came back to find it powered off. I was expecting that it had just died and I would have to restart everything again. But when I turned it on, everything was there. I wasn't paying attention since I was expecting to have to wait for it to boot, so I don't know if it hibernated or suspended. a) did I imagine it that earlier fedoras used to have this feature? It used to. I searched in dconf and found a setting for that, but it is labelled as "no schema found". b) any way I can enable auto-suspect on low battery for F27? Somehow it suddenly started working for me, but I have no idea what triggered it. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org
