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.
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
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.
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
Zbigniew Jędrzejewski-Szmek zbyszek@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
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.
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.
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.
On Wed, Oct 3, 2018 at 5:39 PM Zbigniew Jędrzejewski-Szmek < zbyszek@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.
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
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.
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.
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
On Wed, Oct 3, 2018 at 5:38 PM, Zbigniew Jędrzejewski-Szmek zbyszek@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....
On Thu, Oct 04, 2018 at 04:47:13PM +0200, mcatanzaro@gnome.org wrote:
On Wed, Oct 3, 2018 at 5:38 PM, Zbigniew Jędrzejewski-Szmek zbyszek@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
On Monday, 08 October 2018 at 12:03, Zbigniew Jędrzejewski-Szmek wrote:
On Thu, Oct 04, 2018 at 04:47:13PM +0200, mcatanzaro@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
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@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
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@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?
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 :-)
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.or... "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.or... "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.or... "system now hibernates automatically 3 hours after suspend ?"
(note that those are cross-posted to kernel@fp.o, sometimes fedora-devel@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
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
* Dell Inspiron 1525 with kernel 4.8.13-100.fc23.x86_64 works as expected
* 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 !!!!
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
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@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@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
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@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
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@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
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_for_... (thanks to mattdm for forwarding the fedora-devel thread to reddit)
Zbyszek
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@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...
Hibernating my Lenovo ThinkPad T400 fails frequently because of issues with the installed card reader: https://bugzilla.redhat.com/show_bug.cgi?id=1638014
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.
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.
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.