The “disabled” wakeups do not survive a reboot. You will have to type the echo commands in again to test it again. They will survive a suspend/wake cycle, but not a reboot.
If the tests with the commands work well, then we put them in a config file so that they are activated every time one suspends and are permanent.
The config file looks something like this. You replace the echo lines with the ones that work for you. This file is for a FW16, the echo lines are different for a FW13:
#!/bin/sh
# This file should be placed in: /usr/lib/systemd/system-sleep
PATH=/sbin:/usr/sbin:/bin:/usr/bin
case "$1" in
pre) #echo AMDI0010:03 >/sys/bus/platform/drivers/i2c_designware/unbind
#echo 1-4 >/sys/bus/usb/drivers/usb/unbind
/home/jcd/computer/framework/qmk_hid/target/debug/qmk_hid via --backlight 0
echo disabled > /sys/devices/pci0000:00/0000:00:08.1/0000:c1:00.3/usb1/1-4/1-4.3/power/wakeup
echo disabled > /sys/devices/platform/AMDI0010:03/i2c-1/i2c-PIXA3854:00/power/wakeup
echo disabled >/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:4b/PNP0C09:00/PNP0C0D:00/power/wakeup
exit 0
;;
post) #echo AMDI0010:03 >/sys/bus/platform/drivers/i2c_designware/bind
#echo 1-4 >/sys/bus/usb/drivers/usb/bind
exit 0
;;
*) exit 1
;;
esac
The BIOS writes to the flash of the EC. You don’t need to update the EC firmware on its own, the BIOS will overwrite that.
The EC will reset itself if you leave the laptop powered off (not suspended) for long enough. When you do “ectool console” the numbers at the start of the line are seconds since the EC last rebooted. If you leave the laptop powered off overnight, that should be enough.
You can go into the BIOS and disconnect the battery with a setting if you wish to do the EC reboot quicker, but I don’t think that is the problem here.
I re-applied all the disabled between reboots. Disabling the power/keyboard/touchpad does not consistently allow the computer to sleep.
After a night with the power off the EC has been reset and now I get 95+% sleep without disabling any wakeups. Now the report reads wakeup from IRQ 1 and not the PS/2 controller like the reports before.
Is there a way to isolate if it’s a defective input cover (some hardware on the input cover that is)?
Please can you post a sleep “report” with the power/keyboard/touchpad disabled with the echo commands. I wish to check it is actually disabling what it should.
That “report” is showing it working correctly, you asked for it to sleep for about 60 seconds and it did sleep for about 60 seconds. It is never going to be super accurate time wise, because various devices take different amount of time to “sleep”. Within a few seconds is good enough.
|2024-07-30 22:52:31,648 INFO:|✅ Userspace suspended for 0:01:01.997840|
|---|---|
|2024-07-30 22:52:31,648 DEBUG:|Kernel suspended for total of 0:00:58.791000 (94.83%)|
|2024-07-30 22:52:31,648 INFO:|✅ In a hardware sleep state for 0:00:58.251556 (93.96%)|
Also, it seems to have missed the “lid” disabled, so maybe the echo line for that is currently wrong.
Yes it started sleeping correctly after it was out of battery a whole night but after a day or so it is back to being flaky. This is with the correct wakeups disabled, 4 times 120sec:
By looking at the “report”, I can see all the correct things had wakeup disabled with the echo lines.
Of the 4 times you tested for. The first 2 were bad, the second 2 were good.
Removing the input cover makes the sleeps good. I.e. stay asleep when needed.
Just checking, but how sure are you about the cause being something on the input cover waking it up?
With the input cover present, and wakeup disabled for LID, Keyboard, Touchpad, Power button but it still wakes up.
Fingerprint sensor: This is not causing the problem because you have already tried disabling the fingerprint sensor in the BIOS and it did not help.
Kernel in use: Fedora 40: Kernel 6.9.9-200.fc40.x86_64
The only remaining things to try are:
Chassis Open sensor - I don’t know if this causes a wakeup. I guess you might be able to test it by removing the input cover, suspend, and see if pressing on/off the Chassic open sensor causes it to wake.
Another way to test this would be to partially remove the input cover, leaving the cables connected, but the input cover not pressing the Chassis Open sensor.
The problem seems to be intermittent, in the sense that it wakes up badly only some of the time. Maybe a slightly loose cable on the input cover somewhere?
Something else, but I don’t know what that might be.
I guess a work around for this at the moment, is when you wish the laptop too sleep, use the sleep script with a long sleep time and multi repeats, so if the laptop does wake up, the script sends it to sleep again.
First: I tried the chassis open sensor and it makes no difference.
A cable being loose could be the culprit but wouldn’t it be blocked by the disabling of keyboard, pwr buttong and touchpad wakeups?
To sum up:
I re-did the input cover lidt test just now and it slept 5x5min with and without the cover on.
The problem does in fact seem to be intermittent and not easily reproducible and it’s frankly quite frustrating.
I close and open the computer many times a day so the workaround seems to be fairly involved. Can we somehow disable all wakeups except for the power button and the lid sensor?
This script placed in the right place will disable all wake ups except the Power button. I would be interested to see if it helps or not.
#!/bin/sh
# This file should be placed in directory: /usr/lib/systemd/system-sleep
PATH=/sbin:/usr/sbin:/bin:/usr/bin
case "$1" in
pre)
# Disable all wakeup devices except for the power button
find /sys/devices -path '*/power/wakeup' ! -path '*/PNP0C0C:00/*' |
while read wakeup; do echo disabled > $wakeup; done
exit 0
;;
post)
exit 0
;;
*)
exit 1
;;
esac
» cat /usr/lib/systemd/system-sleep/00-on-sleep-disable-wakeups.sh 1 ↵
#!/bin/sh
# This file should be placed in directory: /usr/lib/systemd/system-sleep
PATH=/sbin:/usr/sbin:/bin:/usr/bin
case "$1" in
pre)
# Disable all wakeup devices except for the power button
find /sys/devices -path '*/power/wakeup' ! -path '*/PNP0C0C:00/*' |
while read wakeup; do echo disabled > $wakeup; done
exit 0
;;
post)
exit 0
;;
*)
exit 1
;;
esac
I forgot to mention, that script runs as it is about to suspend.
So, you kind of need to do one sleep / wake cycle before starting the test.
Otherwise the “Wakeup sources” section in the report is inaccurate.
From the report, it looks like the sleep / wake is working ok.
After the script has run, the “Wakeup sources” section should be very short with only the power button there.
Alternatively, you can manually run the disable all wakeup except power button with:
find /sys/devices -path '*/power/wakeup' ! -path '*/PNP0C0C:00/*' | while read wakeup; do echo disabled > $wakeup; done
If I have the script installed the computer does not wake up from a normal sleep cycle (only from the first one). If I hit sleep in the shutdown menu or close the lid the computer just freezes upon wakeup.
What do you mean by freezes upon wakeup?
So, you press the power button and something happens that shows it exited out of sleep and then it just freezes?
Or, does it never exit from sleep and the fade in/out LED stays in fade in/out mode, thus never exiting from sleep mode?
This is something new, and might be a different bug to look into.
When I disable wakeup from all devices things get a little weird.
The s2idle script does not wake up at the specified interval (which is expected), but does so with the power button. No reaction on keyboard press when it is sleeping.
When I suspend using the sleep button in the KDE menu: same as above, but I return to a locked screen instead of the desktop (as expected).
When I close the lid, open it again I get one or two correct wakeups, but then I am greeted with a black background with a movable cursor. No desktop environment, no login screen, CTRL+ALT+F# does not switch to a TTY.
In this state the keyboard backlight lights up when I press a button on the keyboard, but does not wake the computer up. Only the power button does that, but I can only recover from it with a hard shutdown.
I tested with:
Power plugged in
On battery
With the script in the systemd sleep folder
Running the script manually before causing it to sleep
It seems that the lid close does something more than whatever the s2idle script does.
Edit: The power button was doing the fade in/fade out mode in all modes of sleep in all tests
So, it looks like disabling wakeup on everything is at least making it stay asleep.
That was the aim. i.e. when you “sleep” the laptop, it stays asleep.
Can you confirm that it always stays asleep now?
The no desktop, no login screen is actually a separate, different problem. Its a GPU driver problem.
If you leave it in that state for, say, 5 mins, does it recover?
You might have some luck diagnosing that part if you use an ethernet cable to the laptop, and set up sshd on the laptop and ssh into it from another machine. You might then be able to collect “dmesg” logs.
No it does not stay in hardware sleep but userspace does stay suspended, see s2idle report.
I had to wake it manually, tried to give it a minute the first 4 times and cut it short the last because I could se it didn’t hardware sleep.
There are some messages in dmesg regarding min power state, D3hot:
[ 462.396396] PM: suspend entry (s2idle)
[ 462.407133] Filesystems sync: 0.010 seconds
[ 462.407694] Freezing user space processes
[ 462.410054] Freezing user space processes completed (elapsed 0.002 seconds)
[ 462.410059] OOM killer disabled.
[ 462.410061] Freezing remaining freezable tasks
[ 462.411108] Freezing remaining freezable tasks completed (elapsed 0.001 seconds)
[ 462.411112] printk: Suspending console(s) (use no_console_suspend to debug)
[ 462.411423] wlp1s0: deauthenticating from c0:74:ad:28:33:76 by local choice (Reason: 3=DEAUTH_LEAVING)
[ 462.548807] PM: suspend of devices complete after 137.409 msecs
[ 462.548818] PM: start suspend of devices complete after 137.677 msecs
[ 462.548823] PM: suspend devices took 0.137 seconds
[ 462.549561] Disabling GPIO #5 interrupt for suspend.
[ 462.549588] Disabling GPIO #84 interrupt for suspend.
[ 462.550218] PM: late suspend of devices complete after 1.390 msecs
[ 462.551351] ACPI: EC: interrupt blocked
[ 462.721158] PM: noirq suspend of devices complete after 170.743 msecs
[ 462.721173] ACPI: \_SB_.PCI0.GPP6: LPI: Constraint not met; min power state:D1 current power state:D0
[ 462.721181] ACPI: \_SB_.PCI0.GP11.SWUS: LPI: Constraint not met; min power state:D3hot current power state:D0
[ 462.721186] ACPI: \_SB_.PCI0.GP12.SWUS: LPI: Constraint not met; min power state:D3hot current power state:D0
[ 462.721189] ACPI: \_SB_.PCI0.GPP7.DEV0: LPI: Constraint not met; min power state:D3hot current power state:D0
[ 462.721198] ACPI: \_SB_.PCI0.GP19.XHC2: LPI: Constraint not met; min power state:D3hot current power state:D0
[ 462.721763] ACPI: \_SB_.PEP_: Successfully transitioned to state screen off
[ 462.940639] ACPI: \_SB_.PEP_: Successfully transitioned to state lps0 ms entry
[ 462.941345] ACPI: \_SB_.PEP_: Successfully transitioned to state lps0 entry
[ 462.941672] PM: suspend-to-idle
[ 462.941681] amd_pmc: SMU idlemask s0i3: 0x3ffb3ebd
[ 469.590032] Timekeeping suspended for 6.840 seconds
[ 523.136420] Timekeeping suspended for 52.999 seconds
[ 523.136463] PM: Triggering wakeup from IRQ 9
[ 523.136587] ACPI: EC: ACPI EC GPE status set
[ 523.136614] ACPI: EC: ACPI EC GPE dispatched
[ 523.142788] ACPI: EC: ACPI EC work flushed
[ 523.142797] ACPI: PM: Wakeup after ACPI Notify sync
[ 523.142799] PM: resume from suspend-to-idle
[ 523.143510] ACPI: \_SB_.PEP_: Successfully transitioned to state lps0 exit
[ 523.299276] ACPI: \_SB_.PEP_: Successfully transitioned to state lps0 ms exit
[ 523.299889] ACPI: \_SB_.PEP_: Successfully transitioned to state screen on
[ 523.300366] ACPI: EC: interrupt unblocked
[ 523.489241] PM: noirq resume of devices complete after 189.344 msecs
I think the D3hot is normal. Your very first report in this thread contained them.
My FW16 that does sleep OK has the following:
2024-05-25 14:21:39,892 DEBUG: ACPI: \_SB_.PCI0.GPP6: LPI: Constraint not met; min power state:D1 current power state:D0
2024-05-25 14:21:39,892 DEBUG: ACPI: \_SB_.PCI0.GP11.SWUS: LPI: Constraint not met; min power state:D3hot current power state:D0
2024-05-25 14:21:39,892 DEBUG: ACPI: \_SB_.PCI0.GP12.SWUS: LPI: Constraint not met; min power state:D3hot current power state:D0
2024-05-25 14:21:39,892 DEBUG: ACPI: \_SB_.PCI0.GP19.XHC2: LPI: Constraint not met; min power state:D3hot current power state:D0
2024-05-25 14:21:39,892 DEBUG: ACPI: \_SB_.PEP_: Successfully transitioned to state screen off
2024-05-25 14:21:39,892 DEBUG: ACPI: \_SB_.PEP_: Successfully transitioned to state lps0 ms entry
2024-05-25 14:21:39,892 DEBUG: ACPI: \_SB_.PEP_: Successfully transitioned to state lps0 entry
Please open a new thread for the Black screen after wake issue. That is because its not related to coming out of sleep too early, it is related to a separate GPU driver bug, so we could then link that one to many other threads already discussed on this forum.
