Overview: MacBookAir5,2 doesn't wake from S3 by RTC alarm when lid is closed and power adapter is disconnected. Steps to Reproduce: Run 'rtcwake -m mem -s +15', wait for laptop to go to sleep then close the lid Actual Results: Nothing happens Expected Results: Laptop wakes up in ~15sec Build Date & Hardware: Linux air.plv.loc 5.9.10-arch1-1 #1 SMP PREEMPT Sun, 22 Nov 2020 14:16:59 +0000 x86_64 GNU/Linux MacBookAir5,2 Additional Information: Sleep/resume by lid close/open works fine without any tweaks. But the laptop would resume shortly if suspended with lid open and LID0 enabled in /proc/acpi/wakeup. Anyway, the status of LID0 wakeup doesn't affect RTC wakeup. Wakeup by RTC alarm works if either the lid is open or ADP1 is online.
Created attachment 293869 [details] dmesg
Created attachment 293871 [details] lspci
Created attachment 293873 [details] lsusb
Created attachment 293875 [details] acpi tables
Created attachment 293877 [details] /proc/acpi/wakeup
what do you get by "cat /sys/module/rtc_cmos/parameters/use_acpi_alarm"? if it says N, can you please check if the problem still exists by setting it to Y?
"use_acpi_alarm" was "N". Setting it to "Y" made no difference. A couple of more observations (regardless of use_acpi_alarm setting): the laptop in S3 with RTC alarm set and everything in /proc/acpi/wakeup disabled will wake up by connecting a power supply or by opening the lid.
(In reply to Vadim Pisarev from comment #7) > "use_acpi_alarm" was "N". Setting it to "Y" made no difference. > > A couple of more observations (regardless of use_acpi_alarm setting): the > laptop in S3 with RTC alarm set and everything in /proc/acpi/wakeup disabled > will wake up by connecting a power supply or by opening the lid. what if RTC alarm is not set and everything in /proc/acpi/wakeup disabled, can the laptop wake up by connecting a power supply or by opening the lid? (In reply to Vadim Pisarev from comment #0) > Overview: > MacBookAir5,2 doesn't wake from S3 by RTC alarm when lid is closed and power > adapter is disconnected. please attach the output of "grep . /sys/firmwire/acpi/interrupts/*" both before and after the s3 wake, and also the dmesg log.
Created attachment 295999 [details] dmesg+interrupts Please see the attached archive. It has two directories inside: case1 - regular sleep/resume via lid close/open case2 - same as case1, but RTC alarm is set
(In reply to Zhang Rui from comment #8) > (In reply to Vadim Pisarev from comment #7) > > "use_acpi_alarm" was "N". Setting it to "Y" made no difference. > > > > A couple of more observations (regardless of use_acpi_alarm setting): the > > laptop in S3 with RTC alarm set and everything in /proc/acpi/wakeup > disabled > > will wake up by connecting a power supply or by opening the lid. > > what if RTC alarm is not set and everything in /proc/acpi/wakeup disabled, > can the laptop wake up by connecting a power supply or by opening the lid? No.
(In reply to Vadim Pisarev from comment #9) > Created attachment 295999 [details] > dmesg+interrupts > > Please see the attached archive. It has two directories inside: > > case1 - regular sleep/resume via lid close/open > case2 - same as case1, but RTC alarm is set is case 2 done with Lid closed or opened? Because I don't see the RTC wakeup event fired this time. Please attach the dmesg+interrupts 1. regular suspend using rtcwake, with Lid always open 2. regular suspend using lid close/open 3. failure cause that suspend using rtcwake with Lid closed, and then open lid after like 30 seconds. Plus, it would be good if you can do the same test for freeze mode as well, say rtcwake -m freeze -s 15 instead of rtcwake -m mem -s 15.
(In reply to Zhang Rui from comment #11) > (In reply to Vadim Pisarev from comment #9) > > Created attachment 295999 [details] > > dmesg+interrupts > > > > Please see the attached archive. It has two directories inside: > > > > case1 - regular sleep/resume via lid close/open > > case2 - same as case1, but RTC alarm is set > > is case 2 done with Lid closed or opened? > Because I don't see the RTC wakeup event fired this time. Lid closed. > Please attach the dmesg+interrupts > 1. regular suspend using rtcwake, with Lid always open > 2. regular suspend using lid close/open > 3. failure cause that suspend using rtcwake with Lid closed, and then open > lid after like 30 seconds. > > Plus, it would be good if you can do the same test for freeze mode as well, > say rtcwake -m freeze -s 15 instead of rtcwake -m mem -s 15. See the attached archive. FYI, in freeze/case3 RTC woke up the laptop, but systemd immediately sent it back to freeze. All in all, RTC alarm successfully wakes up the laptop from freeze.
Created attachment 297221 [details] mem/freeze tests
from the dmesg, it seems that the system is doing a full suspend/resume. but I'm not sure if it is the RTC or the Lid that triggers the resume. can you please redo the testcase 3 for mem, with "echo 1 > /sys/power/pm_debug_message" before suspend? say, 1. echo 1 > /sys/power/pm_debug_message 2. echo mem > /sys/power/mem_sleep 3. rtcwake -m mem -t 30 4. open the lid after 60 seconds. In the dmesg, we should see something like "Timekeeping suspended for xx seconds", and this suggests us it is the rtcwake or the lid open that triggers the system wakeup.
My /sys/power/mem_sleep is "s2idle [deep]", so i skipped step #2. The first sleep entry is at ~22 sec. AC adapter is NOT connected, RTC wakeup didn't work. Received the following ACPI events (why ac_adapter?): button/lid LID close processor LNXCPU:00 00000081 00000000 button/lid LID open processor LNXCPU:01 00000081 00000000 processor LNXCPU:02 00000081 00000000 processor LNXCPU:03 00000081 00000000 ac_adapter ACPI0003:00 00000002 00000000 The second sleep entry is at ~77 sec with AC adapter connected. ACPI events: button/lid LID close processor LNXCPU:00 00000081 00000000 processor LNXCPU:01 00000081 00000000 processor LNXCPU:02 00000081 00000000 processor LNXCPU:03 00000081 00000000 button/lid LID open FYI, AC connect events are: ac_adapter ACPI0003:00 00000080 00000001 processor LNXCPU:00 00000081 00000000 processor LNXCPU:01 00000081 00000000 processor LNXCPU:02 00000081 00000000 processor LNXCPU:03 00000081 00000000 AC disconnect: ac_adapter ACPI0003:00 00000080 00000001 processor LNXCPU:00 00000081 00000000 processor LNXCPU:01 00000081 00000000 processor LNXCPU:02 00000081 00000000 processor LNXCPU:03 00000081 00000000
Created attachment 297679 [details] dmesg
> AC disconnect: > > ac_adapter ACPI0003:00 00000080 00000001 My bad, this should be: ac_adapter ACPI0003:00 00000080 00000000
[ 23.000191] PM: Timekeeping suspended for 60.977 seconds [ 78.314604] PM: Timekeeping suspended for 29.050 seconds In the first test, with AC unplugged, the RTC wake event is missing and it is the lid open that triggers the resume. In the second test, with AC plugged, the RTC wake event is fired and triggered the resume. I don't think the Linux kernel does anything special for the RTC fixed event. It is always enabled during the S3 suspend phase. So it is probably a firmware problem instead of Linux issue. Let me think out a way to dump the SCI interrupts to confirm if the RTC fixed event is enabled during resume to confirm this.
Created attachment 297687 [details] debug patch to dump sci during suspend please apply this patch on top of the latest upstream kernel, and make sure you're building the kernel with CONFIG_PM_SLEEP_DEBUG set, and then, with the new kernel, please 1. echo deep > /sys/power/mem_sleep 2. echo 1 > /sys/power/pm_debug_messages 3. with AC plugged, do "dmesg -C; rtcwake -m freeze -s 10; dmesg > dmesg-freeze-ac.log" 4. with AC plugged, do "dmesg -C; rtcwake -m mem -s 10; dmesg > dmesg-mem-ac.log" 5. with AC unplugged, do "dmesg -C; rtcwake -m mem -s 10; dmesg > dmesg-mem-bat.log" and attach the three log files.
Created attachment 297695 [details] dmesg-freeze-ac.log
Created attachment 297697 [details] dmesg-mem-ac.log
Created attachment 297699 [details] dmesg-mem-bat.log