You are not logged in.
Hey!
When I close the lid of my Dell XPS 7390 2-in-1 to put it to S3 sleep it often takes long to suspend and then after opening the lid it takes long to wake up (like 10 s). It doesn't happen every time, but most of the times and when it does happen ACPI errors appear in dmesg log.
I suspended and woken up the laptop 7 times. 2 times were ok, rest of them included a delay on both suspend and wake.
Below I attach a diff comparing a "good" suspend & wake and a "bad", delayed one.
--- .local/log/dmesg.log 2020-10-10 18:09:42.903333712 +0200
+++ .local/log/dmesg-bad-6.log 2020-10-10 18:09:15.896669938 +0200
@@ -1,9 +1,21 @@
PM: suspend entry (deep)
-Filesystems sync: 0.060 seconds
-Freezing user space processes ... (elapsed 0.001 seconds) done.
+Filesystems sync: 0.065 seconds
+Freezing user space processes ... (elapsed 0.003 seconds) done.
OOM killer disabled.
-Freezing remaining freezable tasks ... (elapsed 0.000 seconds) done.
+Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
printk: Suspending console(s) (use no_console_suspend to debug)
+ACPI Error: Aborting method \_SB.PCI0.TDM1.WTBS due to previous error (AE_AML_LOOP_TIMEOUT) (20200528/psparse-529)
+ACPI Error: Aborting method \_SB.PCI0.TDM1.WFCC due to previous error (AE_AML_LOOP_TIMEOUT) (20200528/psparse-529)
+ACPI Error: Aborting method \_SB.PCI0.TDM1._PS0 due to previous error (AE_AML_LOOP_TIMEOUT) (20200528/psparse-529)
+acpi device:8d: Failed to change power state to D0
+ACPI Error: Aborting method \_SB.PCI0.TDM0.WTBS due to previous error (AE_AML_LOOP_TIMEOUT) (20200528/psparse-529)
+ACPI Error: Aborting method \_SB.PCI0.TDM0.WFCC due to previous error (AE_AML_LOOP_TIMEOUT) (20200528/psparse-529)
+ACPI Error: Aborting method \_SB.PCI0.TDM0._PS0 due to previous error (AE_AML_LOOP_TIMEOUT) (20200528/psparse-529)
+acpi device:8c: Failed to change power state to D0
+ACPI Error: Aborting method \_SB.PCI0.TRP2._PS0 due to previous error (AE_AML_LOOP_TIMEOUT) (20200528/psparse-529)
+acpi device:92: Failed to change power state to D0
+ACPI Error: Aborting method \_SB.PCI0.TRP0._PS0 due to previous error (AE_AML_LOOP_TIMEOUT) (20200528/psparse-529)
+acpi device:8e: Failed to change power state to D0
ACPI: EC: interrupt blocked
ACPI: Preparing to enter system sleep state S3
ACPI: EC: event blocked
@@ -38,16 +50,23 @@
CPU7 is up
ACPI: Waking up from system sleep state S3
ACPI: EC: interrupt unblocked
+ACPI Error: Aborting method \_SB.PCI0.TDM0._PS0 due to previous error (AE_AML_LOOP_TIMEOUT) (20200528/psparse-529)
+ACPI Error: Aborting method \_SB.PCI0.TDM1._PS0 due to previous error (AE_AML_LOOP_TIMEOUT) (20200528/psparse-529)
+acpi device:8c: Failed to change power state to D0
+acpi device:8d: Failed to change power state to D0
+ACPI Error: Aborting method \_SB.PCI0.TRP0._PS0 due to previous error (AE_AML_LOOP_TIMEOUT) (20200528/psparse-529)
+ACPI Error: Aborting method \_SB.PCI0.TRP2._PS0 due to previous error (AE_AML_LOOP_TIMEOUT) (20200528/psparse-529)
+acpi device:8e: Failed to change power state to D0
+acpi device:92: Failed to change power state to D0
ACPI: EC: event unblocked
nvme nvme0: 8/0/0 default/read/poll queues
usb 3-10: reset full-speed USB device number 3 using xhci_hcd
usb 3-5: reset full-speed USB device number 2 using xhci_hcd
ish-hid {33AECD58-B679-4E54-9BD9-A04D34F0C226}: [hid-ish]: enum_devices_done OK, num_hid_devices=5
+mei_hdcp 0000:00:16.0-b638ab7e-94e2-4ea2-a552-d1c54b627f04: bound 0000:00:02.0 (ops i915_hdcp_component_ops [i915])
acpi LNXPOWER:03: Turning OFF
OOM killer enabled.
-Restarting tasks ...
-mei_hdcp 0000:00:16.0-b638ab7e-94e2-4ea2-a552-d1c54b627f04: bound 0000:00:02.0 (ops i915_hdcp_component_ops [i915])
-done.
+Restarting tasks ... done.
PM: suspend exit
Bluetooth: hci0: Bootloader revision 0.4 build 0 week 11 2017
Bluetooth: hci0: Device revision is 2
@@ -58,9 +77,9 @@
Bluetooth: hci0: Minimum firmware build 1 week 10 2014
Bluetooth: hci0: Found device firmware: intel/ibt-19-32-4.sfi
Bluetooth: hci0: Waiting for firmware download to complete
-Bluetooth: hci0: Firmware loaded in 1865124 usecs
+Bluetooth: hci0: Firmware loaded in 1848609 usecs
Bluetooth: hci0: Waiting for device to boot
-Bluetooth: hci0: Device booted in 14898 usecs
+Bluetooth: hci0: Device booted in 14781 usecs
Bluetooth: hci0: Found Intel DDC parameters: intel/ibt-19-32-4.ddc
Bluetooth: hci0: Applying Intel DDC parameters completed
Bluetooth: hci0: Firmware revision 0.0 build 121 week 36 2020
As you can see, a couple of lines appear only on a "bad" suspend.
# HERE THE SUSPEND STARTS
# ...
ACPI Error: Aborting method \_SB.PCI0.TDM1.WTBS due to previous error (AE_AML_LOOP_TIMEOUT) (20200528/psparse-529)
ACPI Error: Aborting method \_SB.PCI0.TDM1.WFCC due to previous error (AE_AML_LOOP_TIMEOUT) (20200528/psparse-529)
ACPI Error: Aborting method \_SB.PCI0.TDM1._PS0 due to previous error (AE_AML_LOOP_TIMEOUT) (20200528/psparse-529)
acpi device:8d: Failed to change power state to D0
ACPI Error: Aborting method \_SB.PCI0.TDM0.WTBS due to previous error (AE_AML_LOOP_TIMEOUT) (20200528/psparse-529)
ACPI Error: Aborting method \_SB.PCI0.TDM0.WFCC due to previous error (AE_AML_LOOP_TIMEOUT) (20200528/psparse-529)
ACPI Error: Aborting method \_SB.PCI0.TDM0._PS0 due to previous error (AE_AML_LOOP_TIMEOUT) (20200528/psparse-529)
acpi device:8c: Failed to change power state to D0
ACPI Error: Aborting method \_SB.PCI0.TRP2._PS0 due to previous error (AE_AML_LOOP_TIMEOUT) (20200528/psparse-529)
acpi device:92: Failed to change power state to D0
ACPI Error: Aborting method \_SB.PCI0.TRP0._PS0 due to previous error (AE_AML_LOOP_TIMEOUT) (20200528/psparse-529)
acpi device:8e: Failed to change power state to D0
# ...
# HERE THE WAKE STARTS
# ...
ACPI Error: Aborting method \_SB.PCI0.TDM0._PS0 due to previous error (AE_AML_LOOP_TIMEOUT) (20200528/psparse-529)
ACPI Error: Aborting method \_SB.PCI0.TDM1._PS0 due to previous error (AE_AML_LOOP_TIMEOUT) (20200528/psparse-529)
acpi device:8c: Failed to change power state to D0
acpi device:8d: Failed to change power state to D0
ACPI Error: Aborting method \_SB.PCI0.TRP0._PS0 due to previous error (AE_AML_LOOP_TIMEOUT) (20200528/psparse-529)
ACPI Error: Aborting method \_SB.PCI0.TRP2._PS0 due to previous error (AE_AML_LOOP_TIMEOUT) (20200528/psparse-529)
acpi device:8e: Failed to change power state to D0
acpi device:92: Failed to change power state to D0
Any suggestions how could I debug this further and/or solve this?
Offline
Just so that the same hoops aren't jumped through...
What have you tried so far?
Offline
I tried downgrading kernel, booting linux-lts instead of linux, removing kernel parameters I use to mitigate other issues, updating bios, testing if the issue can be reproduced in a minimal environment: no gui, no wifi/bluetooth, every external device disconnected. I think that's everything.
Offline
# systemctl list-unit-files --state=enabled
Offline
# systemctl list-unit-files --state=enabled
UNIT FILE STATE VENDOR PRESET
getty@.service enabled enabled
iwd.service enabled disabled
lm_sensors.service enabled disabled
nftables.service enabled disabled
systemd-networkd-wait-online.service enabled disabled
systemd-networkd.service enabled enabled
systemd-resolved.service enabled enabled
systemd-timesyncd.service enabled enabled
org.cups.cupsd.socket enabled disabled
systemd-networkd.socket enabled disabled
remote-fs.target enabled enabled
11 unit files listed.
Offline
$ lspci | grep -e VGA -e 3D
Leaning toward power management
Last edited by Zod (2020-10-10 22:09:49)
Offline
Sanity check: how any parallel windows installations do you have?
Offline
$ lspci | grep -e VGA -e 3D
00:02.0 VGA compatible controller: Intel Corporation Iris Plus Graphics G7 (rev 07)
Sanity check: how any parallel windows installations do you have?
None, just encrypted Arch root and boot partition on my ssd.
Offline
Sanity check: how any parallel windows installations do you have?
Ok, gotta ask, any=many? Is that a thing?
Last edited by Zod (2020-10-10 22:40:52)
Offline
seth wrote:Sanity check: how any parallel windows installations do you have?
Ok, gotta ask, any=many? Is that a thing?
I wouldn’t be surprised if someone had 3 windows somewhere in the same box, it IS doable...
Offline
$ pacman -Qi mesa
Is you system up to date?
Offline
$ pacman -Qi mesa
Is you system up to date?
Name : mesa
Version : 20.2.0-2
Description : An open-source implementation of the OpenGL specification
Architecture : x86_64
URL : https://www.mesa3d.org/
Licenses : custom
Groups : None
Provides : mesa-libgl opengl-driver
Depends On : libdrm wayland libxxf86vm libxdamage libxshmfence libelf libomxil-bellagio libunwind llvm-libs lm_sensors libglvnd zstd vulkan-icd-loader
Optional Deps : opengl-man-pages: for the OpenGL API man pages
mesa-vdpau: for accelerated video playback
libva-mesa-driver: for accelerated video playback [installed]
Required By : cogl gst-plugins-base-libs gtk3 lib32-mesa libglvnd qt5-base renderdoc weston wlroots zoom
Optional For : None
Conflicts With : mesa-libgl
Replaces : mesa-libgl
Installed Size : 86.58 MiB
Packager : Evangelos Foutras <foutrelis@archlinux.org>
Build Date : Wed 30 Sep 2020 11:29:19 AM CEST
Install Date : Sat 10 Oct 2020 04:49:03 PM CEST
Install Reason : Installed as a dependency for another package
Install Script : No
Validated By : Signature
Yup, regularly updated.
Offline
Have a look at this.
https://wiki.archlinux.org/index.php/De … n-1_(7390)
I'm still reading it.
This in particular..
https://wiki.archlinux.org/index.php/De … )#S3_Sleep
Edit: Don't forget to read the part about kernel panic.
Last edited by Zod (2020-10-10 23:45:05)
Offline
This in particular..
https://wiki.archlinux.org/index.php/De … )#S3_Sleep
Yes, I'm aware of this issue. I have this setting disabled in BIOS settings. I also disabled VT for Direct I/O when I was getting kernel panics on shutdown and resume and no kernel panics since.
Offline
Ok, now I'm just taking shots...
https://wiki.ubuntu.com/Dell/XPS/XPS-13-7390-2-in-1
Doesn't wake up from suspend on BIOS 1.0.13 with up-to-date 19.10 (2019-12-01) – https://askubuntu.com/questions/1183716 … nd-problem
Workaround: add pcie_aspm=off to kernel cmdline (add to GRUB_CMDLINE_LINUX in /etc/default/grub, and run update-grub*) – this will negatively impact power consumption
* I don't know if you are using grub.
Last edited by Zod (2020-10-11 00:11:56)
Offline
seth wrote:Sanity check: how any parallel windows installations do you have?
Ok, gotta ask, any=many? Is that a thing?
It's a trick question.
"Just one!" is still pointing to windows fast boot as the most likely cause for all sorts of weird ACPI/HW issues - notably around S3.
@krystiancha
Did you also set "mem_sleep_default=deep"?
Do the delay also happen w/o?
Offline
Workaround: add pcie_aspm=off to kernel cmdline (add to GRUB_CMDLINE_LINUX in /etc/default/grub, and run update-grub*) – this will negatively impact power consumption
So this is just another workaround for the "Dell logo" issue mentioned earlier (Early Dell logo display in BIOS).
Unfortunately it doesn't help with the problem I'm experiencing.
Did you also set "mem_sleep_default=deep"?
Yes, I did because I don't really care about the s2idle sleep. It drains my battery and fans spin when my laptop is in my backpack.
Do the delay also happen w/o?
I couldn't reproduce the problem without mem_sleep_default=deep
If I knew that there will be this many issues with this laptop I would have gotten the non 2-in-1 variant which is apparently a lot better on Linux, but I got this one for half price new, so I thought it will be worth it. I mean, it's not that bad, many issues were solved already by the community, but the issue I'm experiencing is apparently new, because I didn't find anyone else experiencing it. Anyway, thanks for the help I received so far.
Also, since I posted here, the issue seems a lot harder to reproduce. The freezes still happen, but less often, I guess it's just unpredictable. Weird, because I haven't really changed anything since in the configuration.
@EDIT
The only thing changing is the battery charge level. Maybe it influences the probability of a freeze on sleep/wake?
@EDIT
the issue seems a lot harder to reproduce
Yeah, so the issue is back at its full intensity. If anyone has any more ideas what I can try to solve this, please let me know.
Last edited by krystiancha (2020-10-18 20:11:54)
Offline
EDIT: Disregard the message below, it doesn't seem to help after all. The same issue popped up again after a few sleep-wakeup cycles.
Hey, I've had the same issues for a while now with the same laptop, and nothing seems to fix it fully. This is also the first time I've heard someone else even mention this issue. The behavior is the same for me: slow wakeup from suspend that seems to happen randomly, and I get a bunch of the same ACPI errors whenever it does.
It seems to be an issue with the power management of some ACPI devices (PCI bus? how would one even find out which device it is?). What does the following return?
cat /sys/bus/acpi/devices/device:{8e,92,8d,8c}/physical_node/power/control
If it's four lines with "auto", it might help to disable the runtime power management for the badly behaving devices:
echo on | sudo tee /sys/bus/acpi/devices/device:{8e,92,8d,8c}/physical_node/power/control
Running this may take a while, and you might get ACPI errors in dmesg, but it should terminate. Check that the output of
cat /sys/bus/acpi/devices/device:{8e,92,8d,8c}/physical_node/power/control
and you should have four lines saying "on".
With this, I've managed to improve the wakeup time a bit, but I'm still not fully satisfied. Let me know if you figure something more out.
Last edited by marchlinux (2020-12-19 00:42:29)
Offline