Created attachment 286715 [details] analyze_suspend logs Hello! I'm using Macbook Pro 11,3 (2013 15") and it failed to suspend on second attempt, only first attempt works fine. I've tried to run analyse tool from https://01.org/blogs/rzhang/2015/best-practice-debug-linux-suspend/hibernate-issues, but it seems do not register any issues and do not check (!) suspend actually works. I ran 'sudo ./analyze_suspend.py -x2 -rtcwake 60' which suppose to suspend for 60 seconds twice in a row, first 60 works, second attempt wakes immediately after 5-15 seconds. I've tried to run proprietary nvidia drivers and open-source nouveau - no difference.
Maybe related issue when backlight start to work after first suspend/resume: https://gitlab.freedesktop.org/mesa/mesa/issues/1181
Created attachment 286727 [details] analyze_suspend 5 tests in a row with nouveau
Disabling XHC1 solves the issue: root@axet-laptop:/proc/acpi# cat wakeup Device S-state Status Sysfs node P0P2 S3 *enabled pci:0000:00:01.0 GFX0 S3 *disabled pci:0000:01:00.0 PEG1 S3 *enabled pci:0000:00:01.1 EC S4 *disabled platform:PNP0C09:00 GMUX S3 *disabled pnp:00:03 HDEF S3 *disabled pci:0000:00:1b.0 RP03 S3 *enabled pci:0000:00:1c.2 ARPT S4 *disabled pci:0000:03:00.0 RP04 S3 *enabled pci:0000:00:1c.3 RP05 S3 *enabled pci:0000:00:1c.4 XHC1 S3 *disabled pci:0000:00:14.0 ADP1 S4 *disabled platform:ACPI0003:00 LID0 S4 *disabled platform:PNP0C0D:00 root@axet-laptop:/proc/acpi# 00:14.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB xHCI (rev 05)
Is this still a issue on latest kernel? I remember there is a fix for this bogus wakeup. thanks.
vmlinuz-5.6.0-050600-generic and vmlinuz-5.7.0-050700rc3-generic unable to resume from suspend.
I tested on v5.8-rc1 kernel on Macbook Pro (2015 13") Core i5 without any extra operations(for example ,disable XHCI wakeup), the suspend to mem works as expected. Could you please help have a check if it works? thx
v5.8-rc2 Unable to test. Failed to start X11 with: "modeset: unable to set mode invalid argument"
(In reply to Alexey Kuznetsov from comment #7) > v5.8-rc2 > > Unable to test. Failed to start X11 with: "modeset: unable to set mode > invalid argument" How about nomodeset in commandline?
Unable to 'open /dev/dri/card0'... I also tried to suspend/resume from console using 'systemctl suspend' and it failed to resume (black screen). Maybe we have to wait until kernell-5.8 will be adopted by debian.
(In reply to Alexey Kuznetsov from comment #9) > Unable to 'open /dev/dri/card0'... I also tried to suspend/resume from > console using 'systemctl suspend' and it failed to resume (black screen). > Maybe we have to wait until kernell-5.8 will be adopted by debian. Okay.
Hi Alexey, may I know the current status of wakeup please?
Hello! My MacbookPro battary has died (bloated) and I have no plans to replace it. Notebook wont boot without a battery (bad design) but here is a trick. MacbookPro has alternate boot mode which allow you to boot this machine without a battery. I call it "no ACPI mode" since kernel showing a lot errors about apple acpi module. To enable it I had to press power, then connect power cable, then release the button. It boots, but sometimes instantly turn off on high power usage when running a game or high cpu task, probably because power adapter not designed to cover power peaks. I had limit CPU usage using governor to 2000mhz. But I still able to test suspend/resume. It failed as before on second suspend cycle as before. tested kernel 5.8.0-0.bpo.2-amd64
(In reply to Alexey Kuznetsov from comment #12) > Hello! > > My MacbookPro battary has died (bloated) and I have no plans to replace it. > Notebook wont boot without a battery (bad design) but here is a trick. > > MacbookPro has alternate boot mode which allow you to boot this machine > without a battery. I call it "no ACPI mode" since kernel showing a lot > errors about apple acpi module. To enable it I had to press power, then > connect power cable, then release the button. It boots, but sometimes > instantly turn off on high power usage when running a game or high cpu task, > probably because power adapter not designed to cover power peaks. I had > limit CPU usage using governor to 2000mhz. > > But I still able to test suspend/resume. It failed as before on second > suspend cycle as before. > > tested kernel 5.8.0-0.bpo.2-amd64 Okay. Is it possible to collect the ./analyze_suspend -m mem -dev -rtcwake 30 result please? (with no_console_suspend appended in boot commandline)
I forget to mention: using NO ACPI MODE makes fun run at full speed, and closing lid has no effect, I had to run 'systemctl suspend' to test suspend/resume. Here is an output: axet@axet-laptop-mac:~/local/suspendresume$ ./analyze_suspend.py -m mem -dev -rtcwake 30 Checking this system (axet-laptop-mac)... have root access: NO (No features of this tool will work!) Try running this script with sudo ERROR: missing root access axet@axet-laptop-mac:~/local/suspendresume$ sudo ./analyze_suspend.py -m mem -dev -rtcwake 30 Checking this system (axet-laptop-mac)... have root access: YES is sysfs mounted: YES is "mem" a valid power mode: YES is ftrace supported: YES are kprobes supported: YES timeline data source: FTRACE (all trace events found) is rtcwake supported: YES optional commands this tool may use for info: turbostat: MISSING mcelog: MISSING lspci: FOUND lsusb: FOUND WARNING: /dev/mem is not readable, ignoring DMI data WARNING: /dev/mem is not readable, ignoring DMI data INITIALIZING FTRACE... INITIALIZING KPROBES... START TRACING SUSPEND START will issue an rtcwake in 30 seconds RESUME COMPLETE CAPTURING DMESG CAPTURING TRACE PROCESSING: suspend-201104-125204/axet-laptop-mac_mem.html DONE: suspend-201104-125204/axet-laptop-mac_mem.html axet@axet-laptop-mac:~/local/suspendresume$ sudo ./analyze_suspend.py -m mem -dev -rtcwake 30 Checking this system (axet-laptop-mac)... have root access: YES is sysfs mounted: YES is "mem" a valid power mode: YES is ftrace supported: YES are kprobes supported: YES timeline data source: FTRACE (all trace events found) is rtcwake supported: YES optional commands this tool may use for info: turbostat: MISSING mcelog: MISSING lspci: FOUND lsusb: FOUND WARNING: /dev/mem is not readable, ignoring DMI data WARNING: /dev/mem is not readable, ignoring DMI data INITIALIZING FTRACE... INITIALIZING KPROBES... START TRACING SUSPEND START will issue an rtcwake in 30 seconds RESUME COMPLETE CAPTURING DMESG CAPTURING TRACE PROCESSING: suspend-201104-131029/axet-laptop-mac_mem.html DONE: suspend-201104-131029/axet-laptop
Created attachment 293447 [details] suspend 1 first suspend
Created attachment 293449 [details] suspend 2 second suspend
Created attachment 293451 [details] suspend 1 dmesg
Created attachment 293453 [details] suspend 2 dmesg
For the html, could you please upload the whole analyze_suspend result dir?
I did file by file (html + dmesg, except ftrace file), ftrace.txt file has uncompressed size of 900M and compressed 50M. Do you need it? I will upload somewhere else then.
(In reply to Alexey Kuznetsov from comment #20) > I did file by file (html + dmesg, except ftrace file), ftrace.txt file has > uncompressed size of 900M and compressed 50M. Do you need it? I will upload > somewhere else then. According to the log, the second suspend did not fail. May I know what the error is during the second suspend? Is it woken up immediately even we set the timeout to 30second? 50M seems to be too large for download(if no other server except bugzilla).Let's use raw suspend for debugging. Could you please append no_console_suspend ignore_loglevel initcall_debug in the boot commandline, and try echo mem > /sys/power/pm_test And wake up via keyboard or power button. and then provide the dmesg
My guess ftrace so large because of NO ACPI MODE. > According to the log, the second suspend did not fail. May I know what > the error is during the second suspend? Is it woken up immediately even we > set the timeout to 30second? This is correct, first suspend / resume feels like 30 second, second feels like 15 seconds long (suspend takes some time) echo mem > /sys/power/pm_test failed with: "bash : echo: write error: Invalid argument" echo mem > /sys/power/state works, second "echo mem" auto wake as before. dmesg follows...
Created attachment 293457 [details] dmesg1 first attempt "echo mem"
Created attachment 293459 [details] dmesg2.log second attempt "echo mem"
100M full logs: https://drive.google.com/file/d/1-7cfcBFUhSk_MFgargbfx-lFSbygeqqz/view?usp=sharing
(In reply to Alexey Kuznetsov from comment #22) > My guess ftrace so large because of NO ACPI MODE. > > > > According to the log, the second suspend did not fail. May I know what > > the error is during the second suspend? Is it woken up immediately even we > > set the timeout to 30second? > > This is correct, first suspend / resume feels like 30 second, second feels > like 15 seconds long (suspend takes some time) > > echo mem > /sys/power/pm_test > > failed with: "bash : echo: write error: Invalid argument" > > echo mem > /sys/power/state > > works, second "echo mem" auto wake as before. dmesg follows... So this issue has been changed to the original one: it is woken up immediately, no other issue(graphic). How about disabling the xhci wake up as we did previously?
Yes, it is about "woken up immediately". And disabling XHCI fixing the issue.