Bug 12013
| Summary: | /sys/class/rtc/rtc0/wakealarm doesn't work, while /proc/acpi/alarm works - Asus P2-M2A690G | ||
|---|---|---|---|
| Product: | Timers | Reporter: | Patrick (24) |
| Component: | Realtime Clock | Assignee: | David Brownell (dbrownell) |
| Status: | RESOLVED OBSOLETE | ||
| Severity: | normal | CC: | acpi-bugzilla, aeriksson, alan, bjoern, buylatestwatch, jb.faq, jeffmclean, jimc, john.stultz, kaja.marik, nm127, odoketa, pc99, rehak.michal, rui.zhang, stefan.andreas.bauer, tony, ville.aakko, yakui.zhao, zucca |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.37 | Subsystem: | |
| Regression: | Yes | Bisected commit-id: | |
| Bug Depends on: | |||
| Bug Blocks: | 56331 | ||
| Attachments: |
acpidump of 2.6.28-rc4
dmesg of 2.6.29 on EeePC 901 acpidump of Asus EeePC 901 Patch for 2.6.29 to get ASUS P4S533 alarm working (not a valid patch proposal) |
||
|
Description
Patrick
2008-11-11 13:56:49 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? 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. (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. 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. 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.
(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 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. Created attachment 18865 [details]
acpidump of 2.6.28-rc4
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. 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 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. 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. 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$ :) Well, I had to read it twice, to see the difference! Thank you. I'll be back soon (have to reboot). 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 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 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.
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. 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.
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 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.
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 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 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. What is HPET-Support? 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. (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! I can confirm this bug also for Gigabyte GA-MA78GM-S2H Board. Disabling HPET helps. 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. (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! 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'. 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. 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. 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
Created attachment 20723 [details]
acpidump of Asus EeePC 901
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.
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. (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 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. (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. 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? Hi, David
Will you please try the following command and see whether it works?
> echo +800 > /sys/class/rtc/rtc0/wakealarm
Thanks.
Hi, echo +800 > /sys/class/rtc/rtc0/wakealarm has fixed the alarm wakeup for me on A8N-SLI Deluxe 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? Created attachment 23087 [details]
Patch for 2.6.29 to get ASUS P4S533 alarm working (not a valid patch proposal)
P.S. I'm currently using nvram-wakeup-1.0 (direct write to CMOS) as an alternative and this seems to be working okay. Just in case it is useful information, the bug is still present in a 2.6.31. 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.)
Just in case it is useful information, the bug is still present in a 2.6.36. Still present in 2.6.37 on Gigabyte GA-MA78GM-S2H. (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. Still present with 2.6.38 on Targa 1526 (needs hpet=disable even to resume from S4 AND S5) I use a gentoo amd64. Please re-open if seen in 3.8+ kernels |