acpi wakeup doesn't work with HP tx2510us unless hpet is disabled

[Pietro Battiston]

I have an HP tx2510.

Following instructions on
http://www.mythtv.org/wiki/index.php/ACPI_Wakeup#Using_.2Fsys.2Fclass.2Frtc.2Frtc0.2Fwakealarm
(which do work on another laptop), it doesn't wake up from sleep.

After giving the commands:

   echo 0 > /sys/class/rtc/rtc0/wakealarm
   echo `date '+%s' -d '+ 200 minutes'` > /sys/class/rtc/rtc0/wakealarm

I can see with

   cat /proc/driver/rtc

that the wakeup seems to be set correctly. But I tried to wait a lot of time (6 hours: notice my local time differs only 1 hour from UTC) and it never wakes up.
Notice that:
- in the BIOS there is no option to enable/disable it, but it does work from Windows Vista. In particular, I tried all the programs from http://acpi-wakeup.qarchive.org/ , and WakeupOnStandby works (while WakeUp and AtriseWakeup don't).
- after (the acpi wakeup didn't work and) I manually wake up the computer, in the output of "cat /proc/driver/rtc" I can see that

    alrm_date : 2008-12-11

has become

    alrm_date : ****-**-**

(while the time line stays unchanged). This is also what happens when I set an alarm in the past, so it seems to me OK.

uname -a says
    Linux vousci 2.6.27-7-generic #1 SMP Tue Nov 4 19:33:06 UTC 2008 x86_64 GNU/Linux

I'm attaching the output of "sudo demidecode".

[24 (24-linux-kernel-bugs)]

Latest working kernel version: 2.6.24

Earliest failing kernel version:

Distribution: Ubuntu 8.10

Hardware Environment: Asus P2-M2A690G

00:00.0 Host bridge: ATI Technologies Inc RS690 Host Bridge
00:01.0 PCI bridge: ATI Technologies Inc RS690 PCI to PCI Bridge (Internal gfx)
00:06.0 PCI bridge: ATI Technologies Inc RS690 PCI to PCI Bridge (PCI Express Port 2)
00:07.0 PCI bridge: ATI Technologies Inc RS690 PCI to PCI Bridge (PCI Express Port 3)
00:12.0 SATA controller: ATI Technologies Inc SB600 Non-Raid-5 SATA
00:13.0 USB Controller: ATI Technologies Inc SB600 USB (OHCI0)
00:13.1 USB Controller: ATI Technologies Inc SB600 USB (OHCI1)
00:13.2 USB Controller: ATI Technologies Inc SB600 USB (OHCI2)
00:13.3 USB Controller: ATI Technologies Inc SB600 USB (OHCI3)
00:13.4 USB Controller: ATI Technologies Inc SB600 USB (OHCI4)
00:13.5 USB Controller: ATI Technologies Inc SB600 USB Controller (EHCI)
00:14.0 SMBus: ATI Technologies Inc SBx00 SMBus Controller (rev 14)
00:14.1 IDE interface: ATI Technologies Inc SB600 IDE
00:14.2 Audio device: ATI Technologies Inc SBx00 Azalia (Intel HDA)
00:14.3 ISA bridge: ATI Technologies Inc SB600 PCI to LPC Bridge
00:14.4 PCI bridge: ATI Technologies Inc SBx00 PCI to PCI Bridge
00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control
01:05.0 VGA compatible controller: ATI Technologies Inc RS690 [Radeon X1200 Series]
01:05.2 Audio device: ATI Technologies Inc Radeon X1200 Series Audio Controller
03:00.0 Ethernet controller: Attansic Technology Corp. L1 Gigabit Ethernet Adapter (rev b0)
04:03.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6306 Fire II IEEE 1394 OHCI Link Layer Controller (rev c0)
04:09.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01)

[ 0.578349] ACPI: RTC can wake from S4
[ 1.868786] rtc_cmos 00:03: rtc core: registered rtc_cmos as rtc0
[ 1.868812] rtc0: alarms up to one month, y3k, hpet irqs

Software Environment:
Video Disk Recorder (VDR)

Problem Description:
After setting the wakeup time via /sys/class/rtc/rtc0/wakealarm, the system
does'nt wake up anymore. RTC runs in UTC
Worked fine on 2.6.24 using /proc/acpi/alarm (Ubuntu 8.04)

Steps to reproduce:
echo 0 > /sys/class/rtc/rtc0/wakealarm
date +%s -d "+4 minutes" > /sys/class/rtc/rtc0/wakealarm
halt

[lenb (lenb-linux-kernel-bugs)]

What if you go back to the old /proc/acpi/alarm
interface by building with CONFIG_RTC_DRV_CMOS=n
Does it still work?

[anonymous (anonymous-linux-kernel-bugs)]

Reply-To: <email address hidden>

does 2.6.28-rc4 work?

does it work if you actually put it to *sleep* (STR, hibernate)
instead of halting it? there was recent fix in that area.

[24 (24-linux-kernel-bugs)]

(In reply to comment #1)
> What if you go back to the old /proc/acpi/alarm
> interface by building with CONFIG_RTC_DRV_CMOS=n
> Does it still work?
>

After compiling Ubuntu 8.10's kernel with CONFIG_RTC_DRV_CMOS=n and setting a wakeup time using /proc/acpi/alarm, my system woke up from S5. That is an acceptable workaround 'til some fix will be made.

Tell me what to do next, to help fixing this problem.

[bsteveker (bsteveker-linux-kernel-bugs)]

I also would like to help. I'm using Mythbuntu 8.10 on my computer (ASUS Pundit2-M2A690G) and ACPI Wakeup doesn't work. It worked with 8.04. If you need some infos please tell me what I have to do.

A fix for this bug would be great because I'm not familiar with compiling kernels. For this reason switching back to /proc/acpi/alarm is at the moment impossible.

Suspend and hibernate don't work because I'm using a Hauppauge PVR 350 with TV-Out and the ivtv driver doesn't wake up properly.

[yakui.zhao (yakui.zhao-linux-kernel-bugs)]

Hi, Patrick
    Will you please try the latest kernel(2.6.28-rc4) and see whether the /sys/class/rtc/rtc*/wakealarm can work?
    After the following commit is merged, the ACPI_FIXED_RTC_EVENT will be enabled when the system enters S5.
    >commit 74c4633da7994eddcfcd2762a448c6889cc2b5bd
    >Author: Rafael J. Wysocki <email address hidden>
    >Date: Tue Sep 2 14:36:11 2008 -0700
       >rtc-cmos: wake again from S5

    Will you please try the latest kernel and see whether the problem still exists?
    Thanks.

[24 (24-linux-kernel-bugs)]

(In reply to comment #5)
> Hi, Patrick
> Will you please try the latest kernel(2.6.28-rc4) and see whether the
> /sys/class/rtc/rtc*/wakealarm can work?

Hi Yakui,

negative, my device will not wakeup from S5 if using 2.6.28-rc4 and /sys/class/rtc/rtc0/wakealarm

regards

[yakui.zhao (yakui.zhao-linux-kernel-bugs)]

Will you please attach the output of acpidump?
   Will you please cat the output of /proc/driver/rtc after wakeup alarm time is set?
   Thanks.

[24 (24-linux-kernel-bugs)]

Created attachment 18865
acpidump of 2.6.28-rc4

[24 (24-linux-kernel-bugs)]

Hi, here you are :)
Still 2.6.28-rc4

knuddel patch # echo 0 > /sys/class/rtc/rtc0/wakealarm
knuddel patch # cat /proc/driver/rtc
rtc_time : 08:33:59
rtc_date : 2008-11-14
alrm_time : 08:38:50
alrm_date : ****-**-14
alarm_IRQ : no
alrm_pending : no
24hr : yes
periodic_IRQ : no
update_IRQ : no
HPET_emulated : yes
DST_enable : no
periodic_freq : 1024
batt_status : okay

knuddel patch # date +s% -d "+14400 minutes" > /sys/class/rtc/rtc0/wakealarm
knuddel patch # cat /proc/driver/rtc
rtc_time : 08:34:57
rtc_date : 2008-11-14
alrm_time : 08:39:54
alrm_date : ****-**-14
alarm_IRQ : no
alrm_pending : no
24hr : yes
periodic_IRQ : no
update_IRQ : no
HPET_emulated : yes
DST_enable : no
periodic_freq : 1024
batt_status : okay

It seems that alarm_IRQ is not set. Also time is not set to +14400 minutes. On Ubuntu's origin 2.6.27 alarm_IRQ and the time were set correctly. I have to reboot to paste it here.

[24 (24-linux-kernel-bugs)]

Hm, that's strange. Now, on origin 2.6.27 kernel, wakeup time can not be set any more. But I'm 100% sure, it was possible before booting newer kernel. Maybe some flags are read only now?

2.6.27 Ubuntu kernel:
knuddel patch # echo 0 > /sys/class/rtc/rtc0/wakealarm
knuddel patch # cat /proc/driver/rtc
rtc_time : 08:47:34
rtc_date : 2008-11-14
alrm_time : 08:52:32
alrm_date : ****-**-14
alarm_IRQ : no
alrm_pending : no
24hr : yes
periodic_IRQ : no
update_IRQ : no
HPET_emulated : yes
DST_enable : no
periodic_freq : 1024
batt_status : okay
knuddel patch # date +s% -d "+14400 minutes" > /sys/class/rtc/rtc0/wakealarm
knuddel patch # cat /proc/driver/rtc
rtc_time : 08:47:43
rtc_date : 2008-11-14
alrm_time : 08:52:41
alrm_date : ****-**-14
alarm_IRQ : no
alrm_pending : no
24hr : yes
periodic_IRQ : no
update_IRQ : no
HPET_emulated : yes
DST_enable : no
periodic_freq : 1024
batt_status : okay

[anonymous (anonymous-linux-kernel-bugs)]

Reply-To: <email address hidden>

On Friday 14 November 2008, <email address hidden> wrote:
> knuddel patch # date +s% -d "+14400 minutes" > /sys/class/rtc/rtc0/wakealarm

Where 14400 minutes == 240 hours == ten days.

Try this wiht something less than ten days at first. Not all
RTCs can support wake events more than 24 hours in the future.

[24 (24-linux-kernel-bugs)]

As you can see here:
knuddel patch # echo 0 > /sys/class/rtc/rtc0/wakealarm
knuddel patch # cat /proc/driver/rtc

and the lines above, wakeup time is even not disabled. But just to be sure:

knuddel patch # echo 0 > /sys/class/rtc/rtc0/wakealarm
knuddel patch # date +s% -d "+20 minutes" > /sys/class/rtc/rtc0/wakealarm
knuddel patch # cat /proc/driver/rtc
rtc_time : 09:46:50
rtc_date : 2008-11-14
alrm_time : 09:51:39
alrm_date : ****-**-14
alarm_IRQ : no
alrm_pending : no
24hr : yes
periodic_IRQ : no
update_IRQ : no
HPET_emulated : yes
DST_enable : no
periodic_freq : 1024
batt_status : okay

Still ~5 minutes, while I set +20 minutes.

[anonymous (anonymous-linux-kernel-bugs)]

Reply-To: <email address hidden>

> knuddel patch # date +s% -d "+20 minutes" > /sys/class/rtc/rtc0/wakealarm

gigo$ date +s% -d '+20 minutes'
s%
gigo$ date +%s -d '+20 minutes'
1226658804
gigo$

[24 (24-linux-kernel-bugs)]

:) Well, I had to read it twice, to see the difference! Thank you. I'll be back soon (have to reboot).

[24 (24-linux-kernel-bugs)]

2.6.28-rc4
knuddel patch # echo 0 > /sys/class/rtc/rtc0/wakealarm
knuddel patch # date +%s -d "+25 minutes" > /sys/class/rtc/rtc0/wakealarm
knuddel patch # cat /proc/driver/rtc
rtc_time : 10:31:10
rtc_date : 2008-11-14
alrm_time : 10:56:09
alrm_date : 2008-11-14
alarm_IRQ : yes
alrm_pending : no
24hr : yes
periodic_IRQ : no
update_IRQ : no
HPET_emulated : yes
DST_enable : no
periodic_freq : 1024
batt_status : okay

And still no wakeup from S5

[htpc (htpc-linux-kernel-bugs)]

Hello,
I can confirm the bug. The wakeup call with Ubuntu 8.10 (Linux 2.6.27-7) doesn't work. I don't have the problem with Ubuntu 8.04.
All tested with Gigabyte MA78GM-S2H

[yakui.zhao (yakui.zhao-linux-kernel-bugs)]

Hi, Patrick
    From the comment #9,10 it seems that the bit of Alarm_IRQ is not set after alarm time is set. But in the comment #15 it seems that the alarm_IRQ bit is set again after alarm time is set.
    Will you please double check it again?
    thanks.

[24 (24-linux-kernel-bugs)]

Hi,

Alarm_IRQ bit is set after setting alarm time. Please forget comment #9, as I have typed "date +s%" instead of "date +%s" and so date did not return a proper value.

[yakui.zhao (yakui.zhao-linux-kernel-bugs)]

Hi, Patrick
    Will you please confirm whether the system can be resumed on the 2.6.28-rc4 kernel if the alarm time is set by /proc/acpi/alarm?
    After setting the alarm time, please attach the output of /proc/driver/rtc.

    Thanks.

[24 (24-linux-kernel-bugs)]

cat /proc/acpi/alarm

2008-11-18 12:06:40

Device woke up from S5

There is no /proc/driver/rtc on my 2.6.28-rc4 if compiled with CONFIG_RTC_DRV_CMOS=n

[yakui.zhao (yakui.zhao-linux-kernel-bugs)]

Hi, Patrick
    thanks for the test. It seems that the system can be waken up from S5 if /proc/acpi/alarm interface is used. But it fails if the /sys/class/rtc/rtc0/wakeup is used.
    Is there anything in /sys/devices/pnp0/00:03/power/wakeup?
    Thanks.

[24 (24-linux-kernel-bugs)]

Hi,

that's right. Using /proc/acpi/alarm works, using the /sys interface does not work.

cat /sys/devices/pnp0/00\:03/power/wakeup
enabled

[zucca (zucca-linux-kernel-bugs)]

i have the same problem here with an asus pundit...
the board seems to be an ASUS M2N8L ACPI BIOS Revision 0404.
since the new kernel wakeup doesn't seem to work anymore...
this is pretty odd...
Plz help...
Thank you very very much !
Sascha

[h.becker (h.becker-linux-kernel-bugs)]

Hi,
I can also confirm the bug with an ASUS M2A-VM HDMI.

But if HPET-Support is disabled in BIOS, wakeup seems
to work as expected.
I have tested with kernel 2.6.28-rc6 and serveral times
turning HPET-Support on and off.
If HPET-Support is turned off, the PC will wake up reliably.

Probably this helps you finding the problem.

[24 (24-linux-kernel-bugs)]

What is HPET-Support?

[24 (24-linux-kernel-bugs)]

Thank you for the hint, Henning!

If I boot my Ubuntu with "hpet=disable" as kernel option, the box will wakeup from S5 using /sys/class/rtc/rtc0/wakealarm - even on the origin 2.6.27 Ubuntu kernel.

[bsteveker (bsteveker-linux-kernel-bugs)]

(In reply to comment #26)
> Thank you for the hint, Henning!
>
> If I boot my Ubuntu with "hpet=disable" as kernel option, the box will wakeup
> from S5 using /sys/class/rtc/rtc0/wakealarm - even on the origin 2.6.27
> Ubuntu
> kernel.
>

Yes, I can confirm this. hpet=disable works! Great!

[pc99 (pc99-linux-kernel-bugs)]

I can confirm this bug also for Gigabyte GA-MA78GM-S2H Board. Disabling HPET helps.

[chichau (chichau-linux-kernel-bugs)]

The bug is confirmed on this ACER AS5920G laptop. However the hpet=disable work around does not work. Wonder if the workaround only works for 32 bit kernel as I am running amd64 kernel. It test with a Mint linux 4.0 live cd and was able to use /proc/acpi/alarm to wakeup the machine.

[h.becker (h.becker-linux-kernel-bugs)]

(In reply to comment #29)
> The bug is confirmed on this ACER AS5920G laptop. However the hpet=disable
> work
> around does not work. Wonder if the workaround only works for 32 bit kernel
> as
> I am running amd64 kernel. It test with a Mint linux 4.0 live cd and was able
> to use /proc/acpi/alarm to wakeup the machine.
>

I also use amd64. Perhaps your kernel is too old and doesn't
contain the patch, mentioned in comment #5?
Try kernel 2.6.28-rc6!

[Pietro Battiston (toobaz)]

Found what seems to be the corresponding upstream bug, in the sense that the suggested workaround, adding "hpet=disable" at boot prompt, works.

[jeffmclean (jeffmclean-linux-kernel-bugs)]

Confirmed on Asus P5GC-MX. When doing "cat /sys/class/rtc/rtc0/wakealarm" nothing happens, no matter how many of the ways above I try to set it. Understandably, PC does not wake when supposed to - the alarm_irq bit is not set to 'yes'.

[tony (tony-linux-kernel-bugs)]

I can confirm this bug also exists on an ASUS P4S533 board, with kernel 2.6.27.9. I've reverted the rtc code to 2.6.26.6 and all is working fine. Using hpet=disable did not fix the problem for me.

[kaja.marik (kaja.marik-linux-kernel-bugs)]

I can confirm this bug also exists on an Asus A7V8X-X board, with kernel 2.6.27.11.

$ sudo sh -c 'echo 0 > /sys/class/rtc/rtc0/wakealarm'
$ sudo sh -c 'echo `date "+%s" -d "+ 5 minutes"` > /sys/class/rtc/rtc0/wakealarm'
$ cat /proc/driver/rtc
rtc_time : 03:50:31
rtc_date : 2009-02-06
alrm_time : 03:55:18
alrm_date : ****-**-06
alarm_IRQ : no
alrm_pending : no
24hr : yes
periodic_IRQ : no
update_IRQ : no
HPET_emulated : no
DST_enable : no
periodic_freq : 1024
batt_status : okay

When checked in bios - wakeup time is changed correctly, wakeup date is not set correctly.

[Andre Schild (andre-schild)]

I see the same problem on my toshiba tecra a9, but hpet=disable does not help.
Should a new bug be opened ?

https://wiki.ubuntu.com/LaptopTestingTeam/ToshibaTecraA9

[petski (petski)]

Andre, same here with a HP Compaq 6710b. I already reported #349768

[Mariner09 (smcmackin)]

I have the same experience from my Lenovo T61 running 2.6.28-11-generic kernel. This was seen from the kernel suspend/resume test script.

[kulight (kulight)]

same problem here my laptop does not wakeup after 20 sec
it only wake up when pressing power button

my laptop is hp compaq 6715s

[linusr (linusr)]

same problem here on Dell Vostro 1500 (with nvidia proprietary driver ) does not wakeup after 20 sec

[kulight (kulight)]

forgot this info

i have a ati card uisng open drivers

************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses.
************************************************************************************

[Beni (benjamin-lutz)]

Samsung Q45 (nvidia) does not wake up after 20sec in kernel suspend/resume test script, too.

[Szabolcs Ladányi (szabolcs-ladanyi)]

same problem here my HP Compaq nx6310 laptop does not wakeup after 20 sec

[foxynet (foxynet)]

same problem here my hp Compay 2150p does not wakeup after 20s in the kernel suspend/resume test script, even with hpet=disable

[nm127 (nm127-linux-kernel-bugs)]

Created attachment 20722
dmesg of 2.6.29 on EeePC 901

The EeePC 901 with kernel 2.6.29 does not wake up also from suspend.

# echo 0 >/sys/class/rtc/rtc0/wakealarm
# echo `date "+%s" -d "+ 5 minutes"` >/sys/class/rtc/rtc0/wakealarm
# cat /proc/driver/rtc
rtc_time : 11:30:31
rtc_date : 2009-03-29
alrm_time : 11:35:20
alrm_date : ****-**-29
alarm_IRQ : no
alrm_pending : no
24hr : yes
periodic_IRQ : no
update_IRQ : no
HPET_emulated : yes
DST_enable : no
periodic_freq : 1024
batt_status : okay

[nm127 (nm127-linux-kernel-bugs)]

Created attachment 20723
acpidump of Asus EeePC 901

[Don Cristóbal (doncristobal)]

Same problem on my IBM T42 with Jaunty Beta.

[Johan Ehnberg (johan-ehnberg)]

Same on AMD790GX desktop jaunty beta.

[H.i.M (hir-i-mogul-gmail)]

Kubuntu Jaunty 64 beta
Does not wakeup after 20s on Sony Vaio VGN-NR320AH.
After manual wakeup Xserver restarts.
Did all the tests in console after Xrestart. (with manual wakeup)

[yakui.zhao (yakui.zhao-linux-kernel-bugs)]

Hi, Marton
    I have an Asus EEEPC 901. But the /sys/class/rtc/rtc0/wakealarm can work well.
    After the alarm time is set correctly, the bit of Alarm IRQ will be set.

    But from the info in comment #34 the bit of Alarm IRQ is unset after the alarm time is set.

    Will you please use the following command and see whether the /sys/class/rtc/rtc0/wakealarm can work ?
    a. echo +800 >/sys/class/rtc/rtc0/wakealarm
    b. cat /proc/driver/rtc

    Thanks.

[toobaz (toobaz-linux-kernel-bugs)]

Some info on which are the boards/laptop affected can be found at https://bugs.launchpad.net/linux/+bug/307090 .

I personally am affected on my HP pavilion tx 2510. When/if some particular testing is appreciated, just ask.

[nm127 (nm127-linux-kernel-bugs)]

(In reply to comment #36)
> Will you please use the following command and see whether the
> /sys/class/rtc/rtc0/wakealarm can work ?
> a. echo +800 >/sys/class/rtc/rtc0/wakealarm
> b. cat /proc/driver/rtc

Yes, in this way it works, it also wakes up the machine at the specified time.

# echo +800 >/sys/class/rtc/rtc0/wakealarm
# cat /proc/driver/rtc
rtc_time : 17:31:49
rtc_date : 2009-03-30
alrm_time : 17:45:05
alrm_date : 2009-03-30
alarm_IRQ : yes
alrm_pending : no
24hr : yes
periodic_IRQ : no
update_IRQ : no
HPET_emulated : yes
DST_enable : no
periodic_freq : 1024
batt_status : okay

However, if I do like this, the alarm_IRQ is "no".

# echo 0 >/sys/class/rtc/rtc0/wakealarm
asus-eeepc:/home/nmarci# date "+%s" -d "+ 5 minutes"
1238427559
asus-eeepc:/home/nmarci# echo `date "+%s" -d "+ 5 minutes"` >/sys/class/rtc/rtc0/wakealarm
asus-eeepc:/home/nmarci# cat /proc/driver/rtc
rtc_time : 17:34:24
rtc_date : 2009-03-30
alrm_time : 17:39:21
alrm_date : ****-**-30
alarm_IRQ : no
alrm_pending : no
24hr : yes
periodic_IRQ : no
update_IRQ : no
HPET_emulated : yes
DST_enable : no
periodic_freq : 1024
batt_status : okay

[Craig Ringer (ringerc)]

Dell XPS M1330 (BIOS revision A06; graphics nVidia 8400M using nvidia-glx-177) also fails to resume after 20s. Manual resume is fine.

[Jan Weiher (jweiher)]

I tried to run the Suspend/Resume Testing script and experienced the same problem. I tried hpet=disable but that did not help at all. Manual resume is fine.
System: Lenovo Ideapad S10e
I'm adding the output of dmidecode to my comment.

[Pietro Battiston (toobaz)]

If hpet=disable does not help, YOU ARE NOT AFFECTED FROM THIS BUG.

If you didn't even test hpet=disable, you may be but may not. Test and then, in case you are, report.

If you are not affected, PLEASE stop posting here reports that have nothing to do.

The page for generic suspend feedback is
https://wiki.ubuntu.com/KernelTeam/SuspendResumeTesting/Feedback

[Craig Ringer (ringerc)]

Tested with hpet=disable. No change, so the XPS M1330 (NVidia 8400M) is *NOT* affected by this specific bug.

[odoketa (odoketa-linux-kernel-bugs)]

This is all a little over my head, but my Lenovo T61 also doesn't resume from suspend:

$ sudo sh -c 'echo 0 > /sys/class/rtc/rtc0/wakealarm'
$ sudo sh -c 'echo `date "+%s" -d "+ 5 minutes"` > /sys/class/rtc/rtc0/wakealarm'
$ cat /proc/driver/rtc
rtc_time : 19:42:37
rtc_date : 2009-04-12
alrm_time : 00:47:27
alrm_date : 2009-04-13
alarm_IRQ : yes
alrm_pending : no
24hr : yes
periodic_IRQ : no
update_IRQ : no
HPET_emulated : yes
DST_enable : no
periodic_freq : 1024
batt_status : okay

my alarm IRQ seems to set reliably each time, but the computer doesn't wake.

[rui.zhang (rui.zhang-linux-kernel-bugs)]

(In reply to comment #39)
> $ sudo sh -c 'echo 0 > /sys/class/rtc/rtc0/wakealarm'
> $ sudo sh -c 'echo `date "+%s" -d "+ 5 minutes"` >
> /sys/class/rtc/rtc0/wakealarm'
> $ cat /proc/driver/rtc
> rtc_time : 19:42:37
> rtc_date : 2009-04-12
> alrm_time : 00:47:27
> alrm_date : 2009-04-13

the computer will probably wakeup in the midnight. :p
this is wrong although I don't know why.

[odoketa (odoketa-linux-kernel-bugs)]

You're absolutely right - last night at 1am it fired up. So it's actually -when- the timer's being set that isn't working. This must be why the suspend/resume test script didn't work for me. If I'd waited long enough it probably would have come back.

Is this a different bug, then? Or did I get the syntax wrong?

[Johan Ehnberg (johan-ehnberg)]

Tested my Asus M4A78T-E (AMD790GX), hpet=disable did not help. NOT affected.

[yakui.zhao (yakui.zhao-linux-kernel-bugs)]

Hi, David
    Will you please try the following command and see whether it works?
    > echo +800 > /sys/class/rtc/rtc0/wakealarm
    Thanks.

[rehak.michal (rehak.michal-linux-kernel-bugs)]

Hi,
echo +800 > /sys/class/rtc/rtc0/wakealarm
has fixed the alarm wakeup for me on A8N-SLI Deluxe

[tony (tony-linux-kernel-bugs)]

I've discovered that if I remove the call to cmos_irq_enable from the function cmos_set_alarm in rtc-cmos.c, then the alarm will work. (This means that RTC_AIE is never set following the CMOS writes to set the alarm time).

See the attached patch for 2.6.29.

Clearly this isn't a final solution as it will break most other RTCs, but if the change works for others too then perhaps someone with more kernel experience than me could explain why removing the call to enable the irq fixes the problem?

[tony (tony-linux-kernel-bugs)]

Created attachment 23087
Patch for 2.6.29 to get ASUS P4S533 alarm working (not a valid patch proposal)

[tony (tony-linux-kernel-bugs)]

P.S. I'm currently using nvram-wakeup-1.0 (direct write to CMOS) as an alternative and this seems to be working okay.

[toobaz (toobaz-linux-kernel-bugs)]

Just in case it is useful information, the bug is still present in a 2.6.31.

[Jeremy Foshee (jeremyfoshee)]

This bug report was marked as Triaged a while ago but has not had any updated comments for quite some time. Please let us know if this issue remains in the current Ubuntu release, http://www.ubuntu.com/getubuntu/download . If the issue remains, click on the current status under the Status column and change the status back to "New". Thanks.

[This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]

[jimc (jimc-linux-kernel-bugs)]

I confirm that the bug is present in kernel 2.6.31.14 (x86 32-bit kernel) from OpenSuSE 11.2. Hardware is a Dell Inspiron 400 "Zino" with:
AMD Athlon 6850e (dual core 64-bit processor)
AMD RS780 Host Bridge
ATI SB700/SB800 SATA Controller (and other Southbridge)
AMD K8 [Athlon64/Opteron] Miscellaneous Control (and other Northbridge)
etc.
    I had the posted symptom that the wake timer is validly set but the machine does not wake. Following Henning Becker's advice, confirmed by Patrick, I set hpet=disable on the kernel command line when booting, then set the timer. Then this machine would wake from S3 (suspend to RAM), S4 (suspend to disc) or S5 (software power off).
    On this machine it doesn't matter whether the hardware clock is set at shutdown (/etc/sysconfig/clock SYSTOHC=yes or no, on a SuSE system), nor does it matter whether a wake time was configured by hand in setup or whether this was disabled. (Other people report that these factors are important on their machines, and that disabling the HPET doesn't help everyone.)

[Pietro Battiston (toobaz)]

I also tested a 2.6.36 kernel today, and the issue is there too.

[toobaz (toobaz-linux-kernel-bugs)]

Just in case it is useful information, the bug is still present in a 2.6.36.

[ville.aakko (ville.aakko-linux-kernel-bugs)]

Still present in 2.6.37 on Gigabyte GA-MA78GM-S2H.

[ville.aakko (ville.aakko-linux-kernel-bugs)]

(In reply to comment #50)
> Still present in 2.6.37 on Gigabyte GA-MA78GM-S2H.

Just adding that using the patch in comment #45 works for me. Are there any downsides is using that patch? Although this question does not belong here, what are the effects of disabling HPET?

FWIW for me too nvram-wakeup also works but I need a reboot after setting wakeup with nvram, which is a hassle.

[jb.faq (jb.faq-linux-kernel-bugs)]

Still present with 2.6.38 on Targa 1526 (needs hpet=disable even to resume from S4 AND S5)
I use a gentoo amd64.

[Brad Figg (brad-figg)]

This bug was filed against a series that is no longer supported and so is being marked as Won't Fix. If this issue still exists in a supported series, please file a new bug.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[alan (alan-linux-kernel-bugs)]

Please re-open if seen in 3.8+ kernels

[buylatestwatch (buylatestwatch-linux-kernel-bugs)]

Who can recommend to me the best product among those in the list on this site?
https://buylatestwatch.com/best-alarm-clock/