10:38 a.m.
We have had a long discussion about hibernate (suspend to disk)
being unreliable. But there seems to be no hard data. Let's gather
some!
If you perform hibernation (systemctl hibernate, or the equivalent
through the GUI), does _your_ system suspend and resume correctly?
Note: I'm not talking about the user-space configuration issues
(resume= not set on the kernel command line, no swap, swap encrypted
with temporary keys, whatever), but only about any potential kernel
driver issues.
My stats (with various version of Fedora):
– thinkpad x1c 4th gen: no issues
– thinkpad x1c 3rd gen: no issues
– thinkpad x230: no issues
– chromebook 2013 model: spurious wakeups after the lid was closed
– thinkpad t50: no issues (*)
– hp pavilion dv7: no issues (*)
So in my own experience, s2d usually works. Does it work for you?
Zbyszek
(*) on this older hardware is where I used hibernation a lot,
on the newer ones, not that much.
11:58 a.m.
On 18-10-03 11:38:20, Zbigniew Jędrzejewski-Szmek wrote:
...
If you perform hibernation (systemctl hibernate, or the equivalent
through the GUI), does _your_ system suspend and resume correctly?
...
Yes.
Acer Aspire E 15 (Aspire ES1-512-P9GT)
For several kernels it wouldn't power off after hibernating[1], but
that seems fixed now.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1602808
--
____________________________________________________________________
TonyN.:' <mailto:tonynelson@georgeanelson.com>
' <http://www.georgeanelson.com/>
12:25 p.m.
Panasonic Toughbook CF-29: Worked fine, though the last time I used that machine was back
in 2015, so can't say anything about recent kernels.
There were a few kernel versions where the machine refused to hibernate - basically, after
2-5 seconds of trying to hibernate it gave up and resumed normal operation - but overall,
it worked fine.
Thinkpad X220: usually works fine. I haven't kept a track of any kind, but generally
the issues I had were one of two types:
- Ridiculously long time to hibernate. Once I actually noted the hour when I pressed
"hibernate" on the keyboard and compared it to when the machine powered off -
and it was an astonishing 8 minutes.
- Similarly to the point above - long time to awake. This always took the form of the
kernel loading the image just fine (and with normal speed), X11 showing up on my screen...
and it's all frozen. The system could then take anywhere from 2 seconds to 4 minutes
until finally - for lack of a more accurate description - the userspace woke up, and then
everything continued working normally as if nothing happened.
1:23 p.m.
On 03/10/2018 16:38, Zbigniew Jędrzejewski-Szmek wrote:
If you perform hibernation (systemctl hibernate, or the equivalent
through the GUI), does _your_ system suspend and resume correctly?
Dell XPS 13 9360 works, once I added a resume option to the
kernel command line, which wasn't previously present.
Tom
--
Tom Hughes (tom(a)compton.nu)
http://compton.nu/
1:38 p.m.
Zbigniew Jędrzejewski-Szmek <zbyszek(a)in.waw.pl> wrote:
If you perform hibernation (systemctl hibernate, or the equivalent
through the GUI), does _your_ system suspend and resume correctly?
On my Clevo W25CEW, hibernation works as a slow way of doing an unclean
reboot: It spends considerable time writing out its memory and then
turns off. When turned on again it displays something like "resuming
from hibernation", but then it goes through the whole normal boot
process.
Of course it's been a long time since I tried, as I know it's pointless.
Note: I'm not talking about the user-space configuration issues
(resume= not set on the kernel command line, no swap, swap encrypted
with temporary keys, whatever), but only about any potential kernel
driver issues.
I don't know whether the above is caused by a kernel driver issue or
not. The swap partition is encrypted with the same passphrase as the
filesystem.
Björn Persson
2:14 p.m.
ASUS P53E: `systemctl hibernate` works, and it resumes correctly, but power indicator says
"Estimating..." until I plug AC adapter out and in again (it was in when both
suspending and resuming).
This is on F29, I recall it not working in F27 or so.
3:01 p.m.
Lenovo Z50-70: Hibernating via `systemctl hibernate` does work, as does
resuming. However, after resuming the machine basically becomes non-
functional until the next boot. It loses connection to the Internet (as
in cannot connect anymore) and seems to get stuck when trying to power
off, forcing me to press the power button to power the machine down.
-----
Dell XPS 13 L322X: Everything works just like it should. Hibernating
works. Suspending works. And after resuming everything works like
normal.
3:11 a.m.
HP pavilion g15-cx0953nd
Got it working by adding resume to grub but it wasn't reliable.
Wakeup failed a few times with no output to screen(s)
The suspect here is the dual-gpu and especially the nvidia card with
proprietary - drivers.
Turned it after needing hard-reset/failsafe 2 times.
3:21 a.m.
On Wed, Oct 3, 2018 at 5:39 PM Zbigniew Jędrzejewski-Szmek <
zbyszek(a)in.waw.pl> wrote:
We have had a long discussion about hibernate (suspend to disk)
being unreliable. But there seems to be no hard data. Let's gather
some!
If you perform hibernation (systemctl hibernate, or the equivalent
through the GUI), does _your_ system suspend and resume correctly?
Note: I'm not talking about the user-space configuration issues
(resume= not set on the kernel command line, no swap, swap encrypted
with temporary keys, whatever), but only about any potential kernel
driver issues.
On all my Thinkpads (R61, T500, X220, T450s, T480s) hibernation worked
correctly once I've dealt with the user space issues (those are usually the
most painful part of the whole process). I've had some rare issues on T500
where resume from hibernation would cause some cpu lockup, but it only
happened when I had a file-based swap, so perhaps it can be attributed to
that.
On my Intel-based desktop (with Gigabyte GA-Z87-D3HP motherboard) the
resume from hibernation failed randomly (probably in about 20% of cases or
so) with errors about e820 memory mapping changed. There were months when
it happened and months when it didn't, so perhaps it was related to the
currently used kernel. After I configured all my USB ports to show up as
XHCI in UEFI setup, the problems seem to have went away. So either this is
a firmware problem on my motherboard, or the kernels have been working fine
since then.
Quite interestingly, regular suspend (to RAM) has been more problematic for
me than hibernation. During certain periods of time (i.e. using certain
kernels), I've seen my laptops immediately resume from suspend every time I
tried it (but hibernation worked fine), or seeing GNOME freeze/crash after
resume (but that can easily be a userspace issue). On my desktop, I see
frequent memory corruption after resume from suspend and I wasn't able to
figure out why (hardware is not faulty), so I had to resort to using
hibernation only.
On the other hand, on average I use regular suspend much more often than
hibernation (also due to GNOME being quite unfriendly to any user choice in
this matter), so maybe that's why I see suspend issues more often than
hibernation issues.
5:57 a.m.
Hi,
on my old workhorse, Asus Sabertooth 990 FX Rel 1 with bios 1604 and 8150FX CPU, I have
occassionally failures on suspending via GUI, My desktop is KDE, F29 and I use
'Application Dashboard -> Suspend' in which case systemd tries to suspend the
box. But sometimes box doesn't sleep at all, instead:
- it either seemingly goes to S3 (i.e. every peripheral powers of and power LED flashes to
indicate S3 state) but power supply does not cut off
- in another case, it goes to S3 but very rapidly powers back on (so that I can hear
PSU's in-rush current limiting relay to loose and close in between about a second)
Now comes the big BUT: If I run following commands from terminal as a root:
sync && echo mem > /sys/power/state
I have not experienced ANY problems at all. For those who had, maybe test this command
compound is worth trying?
Juha
6:02 a.m.
Thinkpad T430 Fedora 28 16GB Ram 16GB Swap with lvm volumes is working.
I had to add the resume parameter manually.
PS: Slightly OT as you specifically only ask if it works. What my biggest problem was with
hibernate is the the "need" of a swap partition. I created mine accidental on
the last SDD upgrade. In general i don't like to waste a ram size part of my harddrive
to lay around not used most of the time. Especially with big ram smaller ssd devices this
is painfull. In my opinion dynamic swap files are the much better option here but AFAIK
this doesn't work with hibernate. If you investigate better usability of hibernate in
general it would be great if you could lock into this too.
7:33 a.m.
Zbigniew Jędrzejewski-Szmek writes:
If you perform hibernation (systemctl hibernate, or the equivalent
through the GUI), does _your_ system suspend and resume correctly?
Note: I'm not talking about the user-space configuration issues
(resume= not set on the kernel command line, no swap, swap encrypted
with temporary keys, whatever), but only about any potential kernel
driver issues.
Well, I don't know if this a kernel or a userspace space issue, but neither
hibernation nor suspension ever worked reliably on my Thinkpad W520. Every
time I tried to enable suspension it works maybe once or twice, but then
eventually the laptop fails to come out of suspended state no matter what,
so I end up power-cycling it, then turning off suspension in power
management, and only have it turn the display off.
Hibernation never worked, to my recollection. Just tried to hibernate this
laptop. The display flickered a few times, the laptop's speaker made a few
reassuring beeps, then the whole thing turned itself off. The next boot was
a normal boot. Normal grub menu, normal boot. No evidence of anything being
hibernated. Probably a userspace issue, but I have no idea where to look.
9:47 a.m.
On Wed, Oct 3, 2018 at 5:38 PM, Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl> wrote:
Note: I'm not talking about the user-space configuration issues
(resume= not set on the kernel command line, no swap, swap encrypted
with temporary keys, whatever), but only about any potential kernel
driver issues.
Well "whatever" is a big deal here, we need to know exactly what is
expected to work and what not before we can test this, or we'll provide
you with false reports that it's broken.
A default install of Fedora with encryption enabled creates swap on
encrypted LVM. Is that expected to work? I'm not planning to
repartition my computer to test this and it's maybe not worth arguing
about if that's not expected to work.
Also, don't forget secure boot, kinda a big deal....
1:35 p.m.
We have had a long discussion about hibernate (suspend to disk)
being unreliable. But there seems to be no hard data. Let's gather
some!
I might have missed something, but can you link me the "long discussion"? Do we
have a page on the subject somewhere on the wiki?
If you perform hibernation (systemctl hibernate, or the equivalent
through the GUI), does _your_ system suspend and resume correctly?
Works perfectly on my T440s :-)
--
Timothée
10:56 p.m.
On 10/3/18 8:38 AM, Zbigniew Jędrzejewski-Szmek wrote:
We have had a long discussion about hibernate (suspend to disk)
being unreliable. But there seems to be no hard data. Let's gather
some!
If you perform hibernation (systemctl hibernate, or the equivalent
through the GUI), does _your_ system suspend and resume correctly?
Note: I'm not talking about the user-space configuration issues
(resume= not set on the kernel command line, no swap, swap encrypted
with temporary keys, whatever), but only about any potential kernel
driver issues.
It works here (all be it with a lock trace in dmesg from ath10k).
Yoga 920.
The experience isn't great here at least though, you do a 'systemctl
hibernate' and the screen blanks immediately. After some time it powers
off, hopefully it worked? On resume: boot, enter luks phrase and... boot
takes some time longer than normal and drops you back to your old
desktop, but there's no progress bar or indicator that it's loading a
hiberate image.
You didn't mention one of the bigest "configuration issues" though:
secure boot has to be disabled. :)
kevin
11:19 a.m.
* Panasonic Toughbook CF-19 with kernel 4.18.11-200.fc28.i686 _DOES NOT_ work as
expected:
- it pretends to save hibernation data and switches off.
- when the computer starts, it begins to read the hibernation data, reboots and start as
normal power-on.
Some funny data:
# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 465,8G 0 disk
[..]
├─sda4 8:4 0 3,9G 0 part [SWAP]
[..]
# swapon --show
NAME TYPE SIZE USED PRIO
/dev/sda4 partition 2G 0B -2
Something wrong with size information !!!!
2:22 a.m.
Yes - works for me, reliably, on a Dell XPS13 L322X - using F27/28. Was a
bit hickuppy in F27, but haven't had any issues with F28 that I can recall.
On Wed, Oct 3, 2018 at 5:39 PM Zbigniew Jędrzejewski-Szmek <
zbyszek(a)in.waw.pl> wrote:
We have had a long discussion about hibernate (suspend to disk)
being unreliable. But there seems to be no hard data. Let's gather
some!
If you perform hibernation (systemctl hibernate, or the equivalent
through the GUI), does _your_ system suspend and resume correctly?
Note: I'm not talking about the user-space configuration issues
(resume= not set on the kernel command line, no swap, swap encrypted
with temporary keys, whatever), but only about any potential kernel
driver issues.
My stats (with various version of Fedora):
– thinkpad x1c 4th gen: no issues
– thinkpad x1c 3rd gen: no issues
– thinkpad x230: no issues
– chromebook 2013 model: spurious wakeups after the lid was closed
– thinkpad t50: no issues (*)
– hp pavilion dv7: no issues (*)
So in my own experience, s2d usually works. Does it work for you?
Zbyszek
(*) on this older hardware is where I used hibernation a lot,
on the newer ones, not that much.
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)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/devel@lists.fedoraproject.org
3:14 a.m.
Does not work on Thinkpad x270 with F28 - kernel 4.18.10-200.
Ended up in terminal with cursor blinking (last thing I saw on start was
resuming from hibernation). I did manual reset after 20 minutes.
On 3.10.2018 17:38, Zbigniew Jędrzejewski-Szmek wrote:
We have had a long discussion about hibernate (suspend to disk)
being unreliable. But there seems to be no hard data. Let's gather
some!
If you perform hibernation (systemctl hibernate, or the equivalent
through the GUI), does _your_ system suspend and resume correctly?
Note: I'm not talking about the user-space configuration issues
(resume= not set on the kernel command line, no swap, swap encrypted
with temporary keys, whatever), but only about any potential kernel
driver issues.
My stats (with various version of Fedora):
– thinkpad x1c 4th gen: no issues
– thinkpad x1c 3rd gen: no issues
– thinkpad x230: no issues
– chromebook 2013 model: spurious wakeups after the lid was closed
– thinkpad t50: no issues (*)
– hp pavilion dv7: no issues (*)
So in my own experience, s2d usually works. Does it work for you?
Zbyszek
(*) on this older hardware is where I used hibernation a lot,
on the newer ones, not that much.
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)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/devel@lists.fedoraproject.org
4:53 a.m.
New subject: hibernation — does it work for you?
On Thu, Oct 04, 2018 at 08:33:13AM -0400, Sam Varshavchik wrote:
I tried to enable suspension it works
maybe once or twice, but then eventually the laptop fails to come
out of suspended state no matter what, so I end up power-cycling it,
then turning off suspension in power management, and only have it
turn the display off.
That's most likely some kernel driver and/or firmware
issue. With suspend,
the userspace just issues the order, and the kernel does the rest.
Hibernation never worked, to my recollection. Just tried to
hibernate this laptop. The display flickered a few times, the
laptop's speaker made a few reassuring beeps, then the whole thing
turned itself off. The next boot was a normal boot. Normal grub
menu, normal boot. No evidence of anything being hibernated.
Probably a userspace issue, but I have no idea where to look.
That sounds as if the
'resume=' parameter is missing from the kernel
command line. The system then just boots normally, which matches the
symptoms you describe.
Zbyszek
5:03 a.m.
New subject: hibernation — does it work for you?
On Thu, Oct 04, 2018 at 04:47:13PM +0200, mcatanzaro(a)gnome.org wrote:
On Wed, Oct 3, 2018 at 5:38 PM, Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl> wrote:
>Note: I'm not talking about the user-space configuration issues
>(resume= not set on the kernel command line, no swap, swap encrypted
>with temporary keys, whatever), but only about any potential kernel
>driver issues.
Well "whatever" is a big deal here, we need to know exactly what is
expected to work and what not before we can test this, or we'll
provide you with false reports that it's broken.
Let's define "works" as "good enough for you as a user for whatever
you use the machine for".
A default install of Fedora with encryption enabled creates swap on
encrypted LVM. Is that expected to work? I'm not planning to
repartition my computer to test this and it's maybe not worth
arguing about if that's not expected to work.
Yes, I have such setup. Usually
the root partition and the swap
partition are very similar. So if dracut is able to figure out how to
decrypt and mount your root partition, it can do the same with swap.
Also, don't forget secure boot, kinda a big deal....
Yeah,
secure boot kills the whole idea. One of the reason why I don't
use secure boot. I hope the kernel reports hibernation as impossible
if secure boot is enabled. It should, and if it doesn't we need to add
a check in systemd. It would be great if somebody with SB enabled could
say what /sys/power/state and /sys/power/disk contain.
Zbyszek
5:13 a.m.
New subject: hibernation — does it work for you?
On Thu, Oct 04, 2018 at 08:35:20PM +0200, Timothée Floure wrote:
> We have had a long discussion about hibernate (suspend to disk)
> being unreliable. But there seems to be no hard data. Let's gather
> some!
I might have missed something, but can you link me the "long discussion"? Do
we
have a page on the subject somewhere on the wiki?
https://lists.fedoraproject.org/archives/list/desktop@lists.fedoraproject...
"Disable (or make configurable and default to off) suspend-then-hibernate behavior
in GNOME-3.30"
https://lists.fedoraproject.org/archives/list/desktop@lists.fedoraproject...
"Disabling kernel's hibernate support by default, allow re-enabling it with a
kernel cmdline option"
https://lists.fedoraproject.org/archives/list/desktop@lists.fedoraproject...
"system now hibernates automatically 3 hours after suspend ?"
(note that those are cross-posted to kernel(a)fp.o, sometimes fedora-devel(a)fp.o, so it's
a bit a thicket to navigate.)
> If you perform hibernation (systemctl hibernate, or the
equivalent
> through the GUI), does _your_ system suspend and resume correctly?
Works perfectly on my T440s :-)
Cool.
Zbyszek
5:19 a.m.
New subject: hibernation — does it work for you?
On Sat, Oct 06, 2018 at 04:19:19PM -0000, Karlis Kalviskis wrote:
* Panasonic Toughbook CF-19 with kernel 4.18.11-200.fc28.i686 _DOES
NOT_ work as expected:
- it pretends to save hibernation data and switches off.
- when the computer starts, it begins to read the hibernation data, reboots and start as
normal power-on.
Some funny data:
# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 465,8G 0 disk
[..]
├─sda4 8:4 0 3,9G 0 part [SWAP]
[..]
# swapon --show
NAME TYPE SIZE USED PRIO
/dev/sda4 partition 2G 0B -2
Something wrong with size information !!!!
Interesting. What does 'sudo file -Ls /dev/sda4' show?
Also, looking at the partition table, does the 3.9GB size match the
space until the next partition?
Zbyszek
5:42 a.m.
New subject: hibernation — does it work for you?
On Monday, 08 October 2018 at 12:03, Zbigniew Jędrzejewski-Szmek wrote:
On Thu, Oct 04, 2018 at 04:47:13PM +0200, mcatanzaro(a)gnome.org wrote:
[...]
> Also, don't forget secure boot, kinda a big deal....
Yeah, secure boot kills the whole idea. One of the reason why I don't
use secure boot. I hope the kernel reports hibernation as impossible
if secure boot is enabled. It should, and if it doesn't we need to add
a check in systemd. It would be great if somebody with SB enabled could
say what /sys/power/state and /sys/power/disk contain.
This is on Fedora 28:
$ dmesg |grep secureboot
[ 0.000000] secureboot: Secure boot enabled
$ cat /sys/power/state
freeze mem
$ cat /sys/power/disk
[disabled]
Regards,
Dominik
--
Fedora https://getfedora.org | RPMFusion http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
5:42 a.m.
New subject: hibernation — does it work for you: quick summary
Various people replied, both here and on reddit [1]. Thank you all!
Short summary:
works (possibly with minor glitches): 27
works but with occasional regressions in some kernel versions: 3
unusable: 10
Results in tabular form:
zbyszek: Thinkpad x1c 4th gen: no issues
zbyszek: Thinkpad x1c 3rd gen: no issues
zbyszek: Thinkpad x230: no issues
zbyszek: Chromebook 2013 model: spurious wakeups after the lid was closed
zbyszek: Thinkpad t50: no issues
zbyszek: HP Pavilion dv7: no issues
Artur Iwicki: Panasonic Toughbook CF-29: works fine, regressions (hib aborts) with some
kernel versions
Thinkpad X220: usually works fine, but sometimes long time to hibernate (8
minutes), long time to wake up
Tony Nelson: Acer Aspire E15 ES1-512-P9GT: fine, but regressions (no poweroff) with some
kernel versions
Akarshan Biswas: Acer Aspire E15 E5-523-98R2: DOESN'T WORK, suspend also broken
Tom Hughes: Dell XPS 13 9360: works
Björn Persson: Clevo W25CEW: resume fails, boots normally instead
Alexander Mikhaylenko: ASUS P53E: works, but power indicator stops reporting status until
cable is replugged
Jani Juhani Sinervo: Lenovo Z50-70: BROKEN (network adapter, poweroff don't work
properly)
Dell XPS 13 L322X: works
Michiel Bodewes: HP pavilion g15-cx0953nd: UNRELIABLE RESUME hard-reset required (dual-gpu
with nvidia prop. driver)
Kamil Paral: Thinkpads R61, X220, T450s, T480s: OK
Thinkpads T500: OK, but rare issues with CPU lockup
Intel desktop with Gigabyte GA-Z87-D3HP: DRIVER PROBLEMS (maybe fixed with
newer kernel versions)
Juha Nikkanen: Asus Sabertooth 990 FX Rel 1 with bios 1604 and 8150FX CP: SOMETIMES WORKS
Enno Zickle: Thinkpad T430: works
Timothée Floure: Thinkpad T440s: works
Kevin Fenzi: Yoga 920: works (lock track in dmesg from ath10k)
Karlis Kalviski: Dell Inspiron 1525: works
Panasonic Toughbook CF-19: NO RESUME (swap partition size screwup)
Jan De Luyck: Dell XPS13 L322X: works
Michal Konečný: Thinkpad x270: NO RESUME (terminal with cursor blinking)
Nom_Ent: Lenovo Thinkpad T420: works (arch)
YouNeverWalkAlone: ThinkPad E470: BROKEN (arch, using ZZZ)
pr0ghead: Gigabyte GA-Z170X-Gaming 7 mainboard with an Intel Core i5-6600K using its IGP:
STOPPED WORKING (kernel 4.17- is fine)
Ben496: Asus Z97i-plus mobo: works (arch)
Asus Zenbook NX500J: works (debian)
elniko77: Lenovo t470: works
yrro: Lenono P50: works (debian)
Toshiba X30: works (debian)
Toshiba X40: works (debian)
Samsung Q45: works (debian)
[If no distribution is mentioned, Fedora is implied.
I included the names of the reporters because otherwise it'd be hard
to find the report. The names are public on the posts anyway.
I ignored the reports which don't include the hardware information.]
[1]
https://www.reddit.com/r/linux/comments/9l3qoe/hibernation_does_it_work_f...
(thanks to mattdm for forwarding the fedora-devel thread to reddit)
Zbyszek
6:31 a.m.
New subject: hibernation — does it work for you?
On Mon, Oct 08, 2018 at 12:42:08PM +0200, Dominik 'Rathann' Mierzejewski wrote:
On Monday, 08 October 2018 at 12:03, Zbigniew Jędrzejewski-Szmek
wrote:
> On Thu, Oct 04, 2018 at 04:47:13PM +0200, mcatanzaro(a)gnome.org wrote:
[...]
> > Also, don't forget secure boot, kinda a big deal....
> Yeah, secure boot kills the whole idea. One of the reason why I don't
> use secure boot. I hope the kernel reports hibernation as impossible
> if secure boot is enabled. It should, and if it doesn't we need to add
> a check in systemd. It would be great if somebody with SB enabled could
> say what /sys/power/state and /sys/power/disk contain.
This is on Fedora 28:
$ dmesg |grep secureboot
[ 0.000000] secureboot: Secure boot enabled
$ cat /sys/power/state
freeze mem
$ cat /sys/power/disk
[disabled]
Thanks!
Zbyszek
8:20 a.m.
New subject: EXTERNAL: Re: hibernation — does it work for you?
On 10/8/18 4:16 AM, Michal Konečný wrote:
Does not work on Thinkpad x270 with F28 - kernel 4.18.10-200.
Nor does it work on Thinkpad x260 with F28 - same kernel
Ended up in terminal with cursor blinking (last thing I saw on start
was resuming from hibernation). I did manual reset after 20 minutes.
On 3.10.2018 17:38, Zbigniew Jędrzejewski-Szmek wrote:
> We have had a long discussion about hibernate (suspend to disk)
> being unreliable. But there seems to be no hard data. Let's gather
> some!
>
> If you perform hibernation (systemctl hibernate, or the equivalent
> through the GUI), does _your_ system suspend and resume correctly?
>
> Note: I'm not talking about the user-space configuration issues
> (resume= not set on the kernel command line, no swap, swap encrypted
> with temporary keys, whatever), but only about any potential kernel
> driver issues.
>
> My stats (with various version of Fedora):
> – thinkpad x1c 4th gen: no issues
> – thinkpad x1c 3rd gen: no issues
> – thinkpad x230: no issues
> – chromebook 2013 model: spurious wakeups after the lid was closed
> – thinkpad t50: no issues (*)
> – hp pavilion dv7: no issues (*)
>
> So in my own experience, s2d usually works. Does it work for you?
>
> Zbyszek
>
> (*) on this older hardware is where I used hibernation a lot,
> on the newer ones, not that much.
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)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/devel@lists.fedoraproject.org
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)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/devel@lists.fedoraproject.org
--
Roger Wells, P.E.
leidos
221 Third St
Newport, RI 02840
401-847-4210 (voice)
401-849-1585 (fax)
roger.k.wells(a)leidos.com
2:07 p.m.
On 10/8/18 3:43 AM, Dominik 'Rathann' Mierzejewski wrote:
On Monday, 08 October 2018 at 12:03, Zbigniew Jędrzejewski-Szmek
wrote:
> On Thu, Oct 04, 2018 at 04:47:13PM +0200, mcatanzaro(a)gnome.org wrote:
[...]
>> Also, don't forget secure boot, kinda a big deal....
> Yeah, secure boot kills the whole idea. One of the reason why I don't
> use secure boot. I hope the kernel reports hibernation as impossible
> if secure boot is enabled. It should, and if it doesn't we need to add
> a check in systemd. It would be great if somebody with SB enabled could
> say what /sys/power/state and /sys/power/disk contain.
This is on Fedora 28:
$ dmesg |grep secureboot
[ 0.000000] secureboot: Secure boot enabled
$ cat /sys/power/state
freeze mem
$ cat /sys/power/disk
[disabled]
That's unfortunate. I have seen some laptops where secure boot can't be
turned off. Is there any way to override that?
7:45 p.m.
New subject: hibernation — does it work for you: quick summary
On 10/8/18 4:42 AM, Zbigniew Jędrzejewski-Szmek wrote:
Various people replied, both here and on reddit [1]. Thank you all!
Short summary:
works (possibly with minor glitches): 27
works but with occasional regressions in some kernel versions: 3
unusable: 10
If I may piggy-back on this thread a bit...
Suspend and hibernate are things that come up in my daily work on a regular
basis; my role so far has been to try to make sure that the kernel can find
(and use) enough info in the ACPI tables on the system so that the kernel can
get both suspend and hibernate to work properly.
This is just part of the issue, of course; we've seen any number of reasons for
failures, from bad ACPI tables, to hardware that doesn't actually know how to
sleep, to systemd or GNOME misbehaving, and in one very odd case a bad mode line
in xorg.conf threw things off.
If I could ask each of you who has responded a favor, if you could please run
the following on the machines reported:
$ sudo dnf install acpica-tools
$ sudo acpidump -o acpi.tables
and send a copy of acpi.tables to ahs3(a)fedoraproject.org with a subject line
telling me what kind of machine it is, I would *greatly* appreciate it. For the
security conscious, this is the same as sending a copy of the contents of
/sys/firmware/acpi/tables; if you have *any* doubts, just don't send the data.
The reason I ask is to get a broader collection of ACPI tables that do and do
not affect suspend/resume. This will help me work on improving the ACPI spec
and on improving the kernel implementation so that we can at least remove as
many of the problems as possible. As Zbigniew has said, empirical data is the
best, but it can be hard to get. I can't guarantee that any given set of ACPI
tables is the actual culprit, nor that I will be able to examine every one of
them in excruciating detail, but it will be another avenue in understanding the
problem better.
Thanks. I now return you to your original thread...
--
ciao,
al
-----------------------------------
Al Stone
Software Engineer
Red Hat, Inc.
ahs3(a)redhat.com
-----------------------------------
8:54 a.m.
Hibernating my Lenovo ThinkPad T400 fails frequently because of issues with the installed
card reader:
https://bugzilla.redhat.com/show_bug.cgi?id=1638014
3:46 p.m.
Works on my Dell XPS 15 9550. But contrary to normal suspend, this takes quite long for
the machine to shut down. It was about 25 seconds and my 16 GB RAM was used up to 8 GB,
but still 25 seconds are a bit long for an SSD.
3:58 p.m.
Works on my Dell XPS 15 9550. But contrary to normal suspend, this takes quite long for
the machine to shut down. It was about 25 seconds and my 16 GB RAM was used up to 8 GB,
but still 25 seconds are a bit long for an SSD.
And I have to say that it killed my `rpm-ostree upgrade` on my F29SB, which I previous
ran. Seems it conflicts with the OSTree state selection in Grub? I think the new OSTree
layer then wasn’t even present there at reboot after hybernate.
4:01 p.m.
Works on my Dell XPS 15 9550. But contrary to normal suspend, this takes quite long for
the machine to shut down. It was about 25 seconds and my 16 GB RAM was used up to 8 GB,
but still 25 seconds are a bit long for an SSD.
And I have to say that it killed my `rpm-ostree upgrade` on my F29SB, which I previous
ran. Seems it conflicts with the OSTree state selection in Grub? The new OSTree layer then
wasn’t even present there at reboot after hybernate (what seems ok) – but it also wasn’t
present there when I rebooted afterwards.
2022
days inactive
2029
days old
33 comments
25 participants
participants (25)
-
Akarshan Biswas -
Al Stone -
Alexander Mikhaylenko -
Artur Iwicki -
Björn Persson -
Dominik 'Rathann' Mierzejewski -
Enno Zickler -
Frank Bx -
Jan De Luyck -
Jani Juhani Sinervo -
Joachim Frieben -
Juha Nikkanen -
Kamil Paral -
Karlis Kalviskis -
Kevin Fenzi -
mcatanzaro＠gnome.org -
Michal Konečný -
Michiel Bodewes -
Sam Varshavchik -
Samuel Sieb -
Timothée Floure -
Tom Hughes -
Tony Nelson -
Wells, Roger K. -
Zbigniew Jędrzejewski-Szmek