Bug 12013 - /sys/class/rtc/rtc0/wakealarm doesn't work, while /proc/acpi/alarm works - Asus P2-M2A690G
Summary: /sys/class/rtc/rtc0/wakealarm doesn't work, while /proc/acpi/alarm works - As...
Status: RESOLVED OBSOLETE
Alias: None
Product: Timers
Classification: Unclassified
Component: Realtime Clock (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: David Brownell
URL:
Keywords:
Depends on:
Blocks: 56331
  Show dependency tree
 
Reported: 2008-11-11 13:56 UTC by Patrick
Modified: 2019-09-27 08:02 UTC (History)
20 users (show)

See Also:
Kernel Version: 2.6.37
Subsystem:
Regression: Yes
Bisected commit-id:


Attachments
acpidump of 2.6.28-rc4 (132.04 KB, text/plain)
2008-11-14 00:38 UTC, Patrick
Details
dmesg of 2.6.29 on EeePC 901 (35.45 KB, text/plain)
2009-03-29 10:31 UTC, Márton Németh
Details
acpidump of Asus EeePC 901 (105.71 KB, text/plain)
2009-03-29 10:34 UTC, Márton Németh
Details
Patch for 2.6.29 to get ASUS P4S533 alarm working (not a valid patch proposal) (402 bytes, patch)
2009-09-13 14:12 UTC, Tony Broad
Details | Diff

Description Patrick 2008-11-11 13:56:49 UTC
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
Comment 1 Len Brown 2008-11-11 20:35:17 UTC
What if you go back to the old /proc/acpi/alarm
interface by building with CONFIG_RTC_DRV_CMOS=n
Does it still work?
Comment 2 Anonymous Emailer 2008-11-11 22:24:17 UTC
Reply-To: david-b@pacbell.net

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.
Comment 3 Patrick 2008-11-12 05:07:22 UTC
(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. 
Comment 4 Stevi 2008-11-12 14:21:56 UTC
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.
Comment 5 ykzhao 2008-11-13 00:11:21 UTC
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 <rjw@sisk.pl>
    >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.
Comment 6 Patrick 2008-11-13 08:54:27 UTC
(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
Comment 7 ykzhao 2008-11-13 17:39:28 UTC
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.
Comment 8 Patrick 2008-11-14 00:38:53 UTC
Created attachment 18865 [details]
acpidump of 2.6.28-rc4
Comment 9 Patrick 2008-11-14 00:39:22 UTC
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.
Comment 10 Patrick 2008-11-14 00:51:41 UTC
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
Comment 11 Anonymous Emailer 2008-11-14 01:37:14 UTC
Reply-To: david-b@pacbell.net

On Friday 14 November 2008, bugme-daemon@bugzilla.kernel.org 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.
Comment 12 Patrick 2008-11-14 01:48:23 UTC
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.
Comment 13 Anonymous Emailer 2008-11-14 02:15:02 UTC
Reply-To: david-b@pacbell.net


> 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$ 
Comment 14 Patrick 2008-11-14 02:18:54 UTC
:) Well, I had to read it twice, to see the difference! Thank you. I'll be back soon (have to reboot).
Comment 15 Patrick 2008-11-14 02:32:12 UTC
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
Comment 16 Klemm 2008-11-14 10:43:32 UTC
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
Comment 17 ykzhao 2008-11-16 17:18:07 UTC
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.
    
Comment 18 Patrick 2008-11-17 10:51:23 UTC
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. 
Comment 19 ykzhao 2008-11-18 01:34:20 UTC
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.
Comment 20 Patrick 2008-11-18 03:42:47 UTC
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
Comment 21 ykzhao 2008-11-18 19:33:15 UTC
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.
Comment 22 Patrick 2008-11-19 02:34:45 UTC
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
Comment 23 Sascha Zucca 2008-11-20 11:11:22 UTC
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
Comment 24 Henning Becker 2008-11-27 05:37:15 UTC
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.
Comment 25 Patrick 2008-11-27 15:14:00 UTC
What is HPET-Support?
Comment 26 Patrick 2008-11-27 15:40:46 UTC
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. 
Comment 27 Stevi 2008-11-27 15:54:25 UTC
(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!
Comment 28 Matthias 2008-11-30 01:40:27 UTC
I can confirm this bug also for Gigabyte GA-MA78GM-S2H Board. Disabling HPET helps.
Comment 29 Paul Chau 2008-11-30 02:27:41 UTC
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.
Comment 30 Henning Becker 2008-11-30 05:09:03 UTC
(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!
Comment 31 Jeff McLean 2008-12-17 18:57:41 UTC
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'.
Comment 32 Tony Broad 2009-01-24 12:23:14 UTC
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.
Comment 33 Karel Marik 2009-02-05 19:21:55 UTC
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.
Comment 34 Márton Németh 2009-03-29 10:31:55 UTC
Created attachment 20722 [details]
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
Comment 35 Márton Németh 2009-03-29 10:34:24 UTC
Created attachment 20723 [details]
acpidump of Asus EeePC 901
Comment 36 ykzhao 2009-03-30 08:10:58 UTC
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.
Comment 37 Pietro Battiston 2009-03-30 10:30:53 UTC
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.
Comment 38 Márton Németh 2009-03-30 15:39:44 UTC
(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
Comment 39 David Barber 2009-04-13 00:52:20 UTC
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.
Comment 40 Zhang Rui 2009-04-13 02:11:37 UTC
(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.
Comment 41 David Barber 2009-04-13 19:46:27 UTC
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?
Comment 42 ykzhao 2009-06-01 00:52:29 UTC
Hi, David
    Will you please try the following command and see whether it works?
    > echo +800 > /sys/class/rtc/rtc0/wakealarm
    Thanks.
Comment 43 michalr 2009-07-03 12:06:12 UTC
Hi,
echo +800 > /sys/class/rtc/rtc0/wakealarm
has fixed the alarm wakeup for me on A8N-SLI Deluxe
Comment 44 Tony Broad 2009-09-13 13:53:28 UTC
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?
Comment 45 Tony Broad 2009-09-13 14:12:32 UTC
Created attachment 23087 [details]
Patch for 2.6.29 to get ASUS P4S533 alarm working (not a valid patch proposal)
Comment 46 Tony Broad 2009-09-13 14:14:48 UTC
P.S. I'm currently using nvram-wakeup-1.0 (direct write to CMOS) as an alternative and this seems to be working okay.
Comment 47 Pietro Battiston 2009-11-29 20:17:02 UTC
Just in case it is useful information, the bug is still present in a 2.6.31.
Comment 48 Jim Carter 2010-11-26 00:12:34 UTC
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.)
Comment 49 Pietro Battiston 2010-12-07 16:12:58 UTC
Just in case it is useful information, the bug is still present in a 2.6.36.
Comment 50 Ville Aakko 2011-02-15 18:35:02 UTC
Still present in 2.6.37 on Gigabyte GA-MA78GM-S2H.
Comment 51 Ville Aakko 2011-02-15 19:11:41 UTC
(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.
Comment 52 Jan Bücken 2011-03-18 14:10:08 UTC
Still present with 2.6.38 on Targa 1526 (needs hpet=disable even to resume from S4 AND S5)
I use a gentoo amd64.
Comment 53 Alan 2013-12-10 16:14:35 UTC
Please re-open if seen in 3.8+ kernels

Note You need to log in before you can comment on or make changes to this bug.