Tuesday 18 August 2009

ACPI Wake Alarm Bugs

A neat feature with most PCs is the ability to program the Real Time Clock (RTC) to trigger an alarm event at some time in the future and wake the PC up. Some projects such as MythTV use this to wake up a PC to record a TV programme. I've used it to make my laptop wake me up when I've forgotten my alarm clock when I've been travelling.

The method of programming the alarm is relatively straight forward - with the older kernels one would write the date and time to wake up into /proc/acpi/alarm and with newer kernels since 2.6.22 use /sys/class/rtc/rtc0/wakealarm. The API documented fairly well at the ACPI wakeup wiki page at mythtv.org.

The ACPI wake alarm is also used by the Ubuntu Kernel Team suspend/resume tests; these tests suspend a laptop for a specific amount of time and re-awaken the machine for programmatic suspend/resume soak testing. Unfortately, we are finding that some machines have a flakey or broken ACPI implementation for the wake alarm - for example, some machines need the alarm setting to zero or being set twice to work.

One can test quite easily of the ACPI wake alarm works - simply program it to trigger in some short time in the future and check to see if the alarm_IRQ field in /proc/driver/rtc is set to "yes". The second test is to wait until the alarm has triggered and check if the same alarm_IRQ field is now set to "no".

I've hacked up a quick-n-dirty test script to check this out and it can be found it my test script git repository here. Run this test and see - if your machine fails then it may be a good idea to check out the MythTV ACPI wake alarm troubleshooting section here. It may be a BIOS bug that's fixed with a new BIOS upgrade. Failing that, one should file a bug with upstream.

So far, I've see this problem on Lenovo 0768 series laptops, but I expect to see it on other machines too.

UPDATE:
It appears the issue is more to do with the hwclock not being in UTC. One can sleep correctly using:

SECS=$((`cat /sys/class/rtc/rtc0/since_epoch`+$SLEEP_SECS))
echo 0 > /sys/class/rtc/rtc0/wakealarm
echo $SECS > /sys/class/rtc/rtc0/wakealarm

Note that I've written to wakealarm twice, the first time writes a zero which apparently helps some buggy BIOSs.

Or the heavy handed way (which will give Windows a headache):

hwclock --utc --systohc

4 comments:

  1. I'm trying to debug an issue: running Mythbuntu 9.10 my PC won't wakeup even when the alarm_IRQ toggles correctly. Some updates ago (which includes a manual update to 2.6.32 kernel in order to use HDMI output with the Intel xorg driver) the computer used to wake up fine. Do you know how to debug this further?

    Thanks
    Antonio

    ReplyDelete
  2. I suggest enabling the CONFIG_ACPI_DEBUG and enabling the relevant ACPI debug settings and see what ACPI reports in the kernel log. Check http://ubuntuforums.org/showpost.php?p=3061038&postcount=6 on how to do this

    ReplyDelete
  3. Searching further I have found this:

    https://lists.linux-foundation.org/pipermail/bugme-janitors/2009-December/018581.html

    It seems to have been fixed in 2.6.33-rc4.

    Thanks a lot anyway for your suggestions.
    Antonio

    ReplyDelete
  4. Hello Colin! I'm alexmoldovan (we spoked on ubuntu-kernel earlier today).I've tried the wakealarm.sh and it says that the ACPI alarm PASSED all the tests. However, I can't seem to make the computer wakeup after a period of time.I use a that sample of a script from checkbox (http://pastebin.ubuntu.com/397848/).On some machines it works, on others it won't.I's clear that the notebooks have poor bios but still I would like to find the core of the problem.I disassembled with iasl the DSDT table (/sys/firmware/acpi/tables/DSDT) in order to see if it has a good Linux entry in it. I got this (http://pastebin.ubuntu.com/398014/) but I don't know weather the values in there are the right ones.I don't know if this is the issue but maybe you could point me into the right direction, or maybe know somebody who could. Do you have any other ideas about what I could try? Thanks!

    ReplyDelete