Created attachment 1668937 [details] kernel logs with eight suspend/resume cycles; last one successful due to workaround 1. Please describe the problem: Installed the 5.5.7-200 kernel and booted into it. After using it for some time, tried to suspend. First time usually works, subsequent attempts fail: system seems to power down for a second (screen goes dark, keyboard LEDs turn off), but then comes back on. It seems to have to do with Bluetooth. I wrote two systemd units (root-suspend, root-resume), that are called on suspend/resume. They run a script to turn Bluetooth off and on, resp. I noticed that I had to insert a sleep(1) after turning off Bluetooth to make it work properly. This may point to the underlying problem: that Bluetooth is not properly turned off before putting the CPU to sleep. I also tried to just insert a sleep(1), but that didn't work: I really had to turn off Bluetooth, and _then_ sleep(1). 2. What is the Version-Release number of the kernel: 5.5.7-200 (but already present in 5.5.2-200 as well) 3. Did it work previously in Fedora? If so, what kernel version did the issue *first* appear? Old kernels are available for download at https://koji.fedoraproject.org/koji/packageinfo?packageID=8 : Suspend worked fine up to and including 5.3.16-300.fc31.x86_64. After that (5.4 series) it has been hit and miss. I cannot say too much about the 5.4 series, since they exhibited bug #1780800, which made the whole 5.4 series unusable for me. I first reported it for kernel 5.5.2-200 in bug #1803706. There I erroneously commented that the issue seemed to have been fixed in 5.5.7. 4. Can you reproduce this issue? If so, please provide the steps to reproduce the issue below: 1. Boot into 5.5.7 kernel. 2. Log in (GNOME desktop). 3. Press power button to suspend. First attempt usually works. 4. Resume. 5. Press power button to suspend again. System powers down for a second, then comes back on (this can be immediate or take several seconds). 5. Does this problem occur with the latest Rawhide kernel? To install the Rawhide kernel, run ``sudo dnf install fedora-repos-rawhide`` followed by ``sudo dnf update --enablerepo=rawhide kernel``: Tested with kernel-core-5.6.0-0.rc5.git0.1.fc33.x86_64, but issue persists. 6. Are you running any modules that not shipped with directly Fedora's kernel?: No, only modules from kernel-core, kernel-modules, kernel-modules-extra 7. Please attach the kernel logs. You can get the complete kernel log for a boot with ``journalctl --no-hostname -k > dmesg.txt``. If the issue occurred on a previous boot, use the journalctl ``-b`` flag. See attached. Eight suspend/resume cycles. First one unsuccessful, second one maybe successful, subsequent 5 cycles unsuccessful, last one successful because of described workaround.
Snippet from attached dmesg: ... Mar 10 12:12:18 kernel: pcieport 0000:02:01.0: BAR 13: no space for [io size 0x1000] Mar 10 12:12:18 kernel: pcieport 0000:02:01.0: BAR 13: failed to assign [io size 0x1000] Mar 10 12:12:59 kernel: xhci_hcd 0000:39:00.0: can't change power state from D3cold to D0 (config space inaccessible) Mar 10 12:12:59 kernel: xhci_hcd 0000:39:00.0: can't change power state from D3hot to D0 (config space inaccessible) Mar 10 12:12:59 kernel: xhci_hcd 0000:39:00.0: Controller not ready at resume -19 Mar 10 12:12:59 kernel: xhci_hcd 0000:39:00.0: PCI post-resume error -19! Mar 10 12:12:59 kernel: xhci_hcd 0000:39:00.0: HC died; cleaning up Mar 10 12:12:59 kernel: xhci_hcd 0000:39:00.0: remove, state 4 Mar 10 12:12:59 kernel: usb usb4: USB disconnect, device number 1 Mar 10 12:12:59 kernel: xhci_hcd 0000:39:00.0: USB bus 4 deregistered Mar 10 12:12:59 kernel: xhci_hcd 0000:39:00.0: remove, state 4 Mar 10 12:12:59 kernel: usb usb3: USB disconnect, device number 1 Mar 10 12:12:59 kernel: xhci_hcd 0000:39:00.0: Host halt failed, -19 Mar 10 12:12:59 kernel: xhci_hcd 0000:39:00.0: Host not accessible, reset failed. Mar 10 12:12:59 kernel: xhci_hcd 0000:39:00.0: USB bus 3 deregistered ...
Do you have a lot of USB devices connected? If so, have you tried disconnecting them and then testing suspend? Can you suspend if you disable your Bluetooth devices? Also, there is a kernel update available: kernel-5.5.8-200.fc31, kernel-headers-5.5.8-200.fc31, & 1 more https://bodhi.fedoraproject.org/updates/FEDORA-2020-d8c4450b82 Snippets from attached dmesg: ... Mar 10 12:11:12 kernel: hub 1-0:1.0: USB hub found Mar 10 12:11:12 kernel: hub 1-0:1.0: 12 ports detected ... Mar 10 12:13:36 kernel: hid-generic 0005:046D:B012.0002: input,hidraw1: BLUETOOTH HID v0.14 Keyboard [MX Master] on 74:e5:f9:d0:49:b7 ...
I have no USB devices connected, and the only Bluetooth connected device is a mouse (the MX Master that is mentioned in dmesg; funny that it's reported as a keyboard). As I wrote in the description, I created a systemd trigger that disables Bluetooth before suspend (allowing it to settle for 1 second). If I use that (or manually turn off Bluetooth before suspending), then suspend works fine. Anyhow, I'll check out kernel-5.5.8-200 and report back.
(In reply to Steven Bakker from comment #3) > I have no USB devices connected, and the only Bluetooth connected device is > a mouse (the MX Master that is mentioned in dmesg; funny that it's reported > as a keyboard). Thanks for your follow-up reply. There are mouse entries too, but they don't mention Bluetooth: $ fgrep MX -m3 dmesg.txt Mar 10 12:13:36 kernel: input: MX Master Keyboard as /devices/virtual/misc/uhid/0005:046D:B012.0002/input/input30 Mar 10 12:13:36 kernel: input: MX Master Mouse as /devices/virtual/misc/uhid/0005:046D:B012.0002/input/input31 Mar 10 12:13:36 kernel: hid-generic 0005:046D:B012.0002: input,hidraw1: BLUETOOTH HID v0.14 Keyboard [MX Master] on 74:e5:f9:d0:49:b7 Could you attach dmesg for 5.3.16-300.fc31.x86_64, so we can compare those input device names? > As I wrote in the description, I created a systemd trigger that disables > Bluetooth before suspend (allowing it to settle for 1 second). If I use that > (or manually turn off Bluetooth before suspending), then suspend works fine. OK. For completeness, could you post or attach your systemd unit files? And could you clarify this: Are those intended only as a workaround for the suspend problem, or do you need them for another reason? > Anyhow, I'll check out kernel-5.5.8-200 and report back. OK.
Hi, See the attached dmesg-5.3.6-300.txt and dmesg-5.5.8-200.txt. Regarding the MX Master entries: these come from my Bluetooth Logitech MX Master mouse. In the runs included in this update, I did *not* turn on this mouse (so it doesn't show up in the logs). All other USB devices are internal to the laptop. Under 5.3.16-300 I suspended and resumed twice, both times successfully. Under 5.5.8-200 I suspended three times: the first two times failed (screen goes off, LEDs go off, then after one or two seconds, it turns back on); the third time, I manually turned off Bluetooth before suspending, and that worked. I've also included the systemd files (two unit files and a Perl script). These are only meant as a workaround for the suspend issue, and it only works reliably if the script first turns off Bluetooth and then sleeps for a second (without the sleep it is hit and miss). One significant difference I noticed between 5.3.16 and 5.5.8 (or 5.5 in general, I guess) is how "deep" the system sleeps: in 5.3.16, the system wakes up when I click the trackpad, but not when I hit keys on the keyboard. On 5.5.8 (and previous 5.5 kernels), a keyboard press will wake up the system as well (even with Bluetooth turned off). I guess there have been significant changes in the suspend mechanism between 5.3 and 5.5. The erratic suspend behaviour seems to have started with the 5.4 kernel series, but I never had a chance to test this all too well because of the instabilities in the Intel graphics driver.
Created attachment 1669648 [details] kernel logs for 5.3.16-300
Created attachment 1669650 [details] kernel logs for 5.5.8-200
Created attachment 1669652 [details] Systemd unit files and Perl script to turn Bluetooth off/on on suspend/resume
Thanks for the attachments and the clarifications, and for disabling the MX Master mouse. The trackpad sometimes fails to suspend with both kernels. And there is a difference in the sleep state: "deep" vs. "s2idle": $ egrep 'psmouse|suspend entry|suspend exit' dmesg-5.3.16-300.txt Mar 12 13:16:10 kernel: psmouse serio1: synaptics: queried max coordinates: x [..5666], y [..4734] Mar 12 13:16:10 kernel: psmouse serio1: synaptics: queried min coordinates: x [1276..], y [1118..] Mar 12 13:16:10 kernel: psmouse serio1: synaptics: Your touchpad (PNP: DLL075b PNP0f13) [... removed ...] Mar 12 13:16:10 kernel: psmouse serio1: synaptics: Touchpad model: 1, fw: 8.2, id: 0x1e2a1 [... removed ...] Mar 12 13:18:06 kernel: PM: suspend entry (deep) Mar 12 13:18:21 kernel: psmouse serio1: Failed to disable mouse on isa0060/serio1 Mar 12 13:18:21 kernel: PM: suspend exit Mar 12 13:18:35 kernel: PM: suspend entry (deep) Mar 12 13:18:41 kernel: PM: suspend exit Mar 12 13:19:05 kernel: PM: suspend entry (deep) Mar 12 13:19:34 kernel: PM: suspend exit $ egrep 'psmouse|suspend entry|suspend exit' dmesg-5.5.8-200.txt Mar 12 13:20:28 kernel: psmouse serio1: synaptics: Unable to query device: -5 Mar 12 13:20:34 kernel: psmouse serio1: Failed to enable mouse on isa0060/serio1 Mar 12 13:22:19 kernel: PM: suspend entry (s2idle) Mar 12 13:22:24 kernel: psmouse serio1: Failed to disable mouse on isa0060/serio1 Mar 12 13:22:24 kernel: PM: suspend exit Mar 12 13:22:49 kernel: PM: suspend entry (s2idle) Mar 12 13:22:50 kernel: PM: suspend exit Mar 12 13:23:15 kernel: PM: suspend entry (s2idle) Mar 12 13:23:23 kernel: PM: suspend exit
The suspend and resume times are significantly different: $ grep 'took' dmesg-5.3.16-300.txt Mar 12 13:18:21 kernel: PM: suspend devices took 1.130 seconds Mar 12 13:18:21 kernel: PM: resume devices took 0.600 seconds Mar 12 13:18:41 kernel: PM: suspend devices took 0.118 seconds Mar 12 13:18:41 kernel: PM: resume devices took 0.658 seconds Mar 12 13:19:34 kernel: PM: suspend devices took 0.119 seconds Mar 12 13:19:34 kernel: PM: resume devices took 0.647 seconds $ grep 'took' dmesg-5.5.8-200.txt Mar 12 13:22:24 kernel: PM: suspend devices took 0.641 seconds Mar 12 13:22:24 kernel: PM: resume devices took 0.248 seconds Mar 12 13:22:50 kernel: PM: suspend devices took 0.039 seconds Mar 12 13:22:50 kernel: PM: resume devices took 0.240 seconds Mar 12 13:23:23 kernel: PM: suspend devices took 0.035 seconds Mar 12 13:23:23 kernel: PM: resume devices took 0.255 seconds
This could be the same bug: Bug 1812055 - Suspend cancelled
FYI, this persists up to kernel 5.5.11 (will try 5.5.13 next) Also, hibernate does not work. System seems to hibernate, but when I turn it on again, it just (re)boots.
The "s2idle" vs. "deep" seems to be the issue here. Found a bug on Launchpad: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1808957 This mentions exactly this problem. For some reason, recent kernels set the default mem_sleep to "s2idle" instead of "deep", and the Dell XPS 13 does not handle that too well (it wakes up too easily, and drains way too much power in that state). Simple solution: echo deep | sudo dd of=/sys/power/mem_sleep To make this stick, either edit /etc/default/grub (as mentioned in the Launchpad bug above), or use grubby: sudo grubby --update-kernel=ALL --args="mem_sleep_default=deep" Alternatively, if you're feeling freaky: --- snip --- sudo dd of=/etc/rc.c/rc.local <<EOF #!/bin/sh echo deep > /sys/power/mem_sleep EOF sudo chmod +x /etc/rc.d/rc.local --- snip --- It's crude, but it saves my battery (and my sanity) for now.
Thanks for your followup report and for your workarounds. You can change kernel parameter values in: /etc/sysctl.conf or by adding a file here: /etc/sysctl.d/ See, also: $ sysctl -a NB: /etc/sysctl.d/99-sysctl.conf is a link to ../sysctl.conf. So it would probably be best to add your own file: /etc/sysctl.d/01-local.conf Documentation: $ man sysctl.conf $ man sysctl.d $ man sysctl
(In reply to Steve from comment #14) ... > See, also: > > $ sysctl -a ... Apparently, none of that will work. sysctl is restricted to "parameters ... listed under /proc/sys/." (per "man sysctl") $ sysctl power.mem_sleep sysctl: cannot stat /proc/sys/power/mem_sleep: No such file or directory And this doesn't find anything: $ find /proc/sys/ -name mem_sleep $
(In reply to Steven Bakker from comment #13) > For some reason, recent kernels set the default mem_sleep to "s2idle" instead of "deep", ... There is this sentence: "On some systems with ACPI, depending on the information in the ACPI tables, the default may be “s2idle” even if suspend-to-RAM is supported in principle." At the very end of: System Sleep States https://www.kernel.org/doc/html/latest/admin-guide/pm/sleep-states.html So it sounds like there is a regression here, unless the "ACPI tables" changed with your kernel update.
> mem_sleep_default=deep Could you temporarily revert your workaround so we can see what the files in /sys/power/ have in them: $ grep -s '' /sys/power/* And for the completeness: $ uname -r $ cat /proc/cmdline
> Suspend worked fine up to and including 5.3.16-300.fc31.x86_64. After that (5.4 series) it has been hit and miss. If you have one of those older kernels, could you repeat the commands in Comment 17 after booting with it. If not, the rescue kernel might do the trick. You can check the version of the rescue kernel without booting it with: $ file /boot/vmlinuz-0-rescue-*
Created attachment 1677733 [details] /sys/power files for kernel 5.5.15-200.fc31.x86_64
Created attachment 1677734 [details] /proc/cmdline for kernel 5.5.15-200.fc31.x86_64
Created attachment 1677735 [details] /sys/power files for kernel 5.3.16-300.fc31.x86_64
Created attachment 1677736 [details] /proc/cmdline for kernel 5.3.16-300.fc31.x86_64
I just attached four files: sys_power_5.3.16-300.fc31.x86_64.txt, sys_power_5.5.15-200.fc31.x86_64.txt, cmdline_5.3.16-300.fc31.x86_64.txt, cmdline_5.5.15-200.fc31.x86_64.txt.
(In reply to Steven Bakker from comment #23) > I just attached four files: sys_power_5.3.16-300.fc31.x86_64.txt, sys_power_5.5.15-200.fc31.x86_64.txt, cmdline_5.3.16-300.fc31.x86_64.txt, cmdline_5.5.15-200.fc31.x86_64.txt. Thanks. It's just as you say: sys_power_5.3.16-300.fc31.x86_64.txt: /sys/power/mem_sleep:s2idle [deep] /sys/power/pm_trace_dev_match:i2c sys_power_5.5.15-200.fc31.x86_64.txt: /sys/power/mem_sleep:[s2idle] deep [/sys/power/pm_trace_dev_match is absent] For reference, here is what my F30 desktop system has for those: 5.5.10-100.fc30.x86_64: /sys/power/mem_sleep:s2idle [deep] /sys/power/pm_trace_dev_match:tty And my F30 laptop: 5.5.13-100.fc30.x86_64: /sys/power/mem_sleep:s2idle [deep] [/sys/power/pm_trace_dev_match is absent]
(In reply to Steven Bakker from comment #5) ... > I've also included the systemd files (two unit files and a Perl script). > These are only meant as a workaround for the suspend issue, and it only > works reliably if the script first turns off Bluetooth and then sleeps for a > second (without the sleep it is hit and miss). ... Do you still need the systemd unit files to suspend the Bluetooth device when using the "echo deep > /sys/power/mem_sleep" workaround? IOW, do need both workarounds or have you replaced one workaround with another workaround?
No, I don't need the Bluetooth workaround anymore (that was only necessary for s2idle).
(In reply to Steven Bakker from comment #26) > No, I don't need the Bluetooth workaround anymore (that was only necessary for s2idle). Thanks for confirming that. I found this commit, which explicitly mentions your model: ACPI: PM: Drop Dell XPS13 9360 from LPS0 Idle _DSM blacklist (committed 2019-10-10) https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2189624b3c5a6fb03416129e35c09aa5151b7392 The commit message has a link to this upstream bug: Bug_196907 - [Regression] s2idle does not work with PC300 NVMe SK hynix 512GB - Dell XPS 13 9360 https://bugzilla.kernel.org/show_bug.cgi?id=196907 From the attached log: $ grep DMI: dmesg-5.5.8-200.txt Mar 12 13:20:27 kernel: DMI: Dell Inc. XPS 13 9360/0PF86Y, BIOS 2.13.0 11/14/2019
Marc C in Bug 1834277, Comment 6, reports a Dell-specific workaround for the s2idle-default problem. Simply disable the "Sign of Life" options in the BIOS. The "Sign of Life" options are documented here: Dell XPS 13 9300 Service Manual, page 46 https://topics-cdn.dell.com/pdf/xps-13-9300-laptop_service-manual_en-us.pdf
(In reply to Steve from comment #28) > Marc C in Bug 1834277, Comment 6, reports a Dell-specific workaround for the s2idle-default problem. > > Simply disable the "Sign of Life" options in the BIOS. The "Sign of Life" options are documented here: > > Dell XPS 13 9300 Service Manual, page 46 > https://topics-cdn.dell.com/pdf/xps-13-9300-laptop_service-manual_en-us.pdf That may not work: Bug 1834277, Comment 8.
This message is a reminder that Fedora 31 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '31'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 31 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 31 changed to end-of-life (EOL) status on 2020-11-24. Fedora 31 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.