Red Hat Bugzilla – Bug 449738
Wakeup on RTC alarm does not work anymore
Last modified: 2008-09-10 03:11:37 EDT
Description of problem:
I've 4 identical PCs (P4 4GHz, with 2GiB, from 2005) and an old one (P-III
500MHz, with 512MiB).
One P4 and the old P-III are now with F9, while the others are still with F8.
Two of the P4 with F8 have a cronjob which writes a wakeup date on
/proc/acpi/alarm and then poweroff.
This works fine, the machines go to poweroff (or S5) on Friday evening and then
they wakeup on Monday morning.
On the F9 machines, the /proc/acpi/alarm is gone and "rtcwake" should be used to
set the wakeup alarm and suspend (note that S5 is, at the moment, unsupported in
This seems *not* to work properly.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
rtcwake -s 30 -m disk
The P-III wakes up without problems, the P4 does not wakeup... Never...
The P4 should wake up.
The F8 kernel is 18.104.22.168-92.fc8
It is kind of difficult to cross test, since F8 does not support "rtcwake" and
F9 does not support /proc/alarm/acpi, so any suggestion is welcome.
This issue is kind of urgent, since it is a showstopper for the F8->F9 upgrade.
I was able to suspend-to-disk on one of the F8 machines, setting the wakeup
timer with the usual echo xxx >/proc/acpi/alarm.
I can confirm the wakeup occurs also from S2D with F8.
I checked another F9 machine, this one is an x86_64.
Also in this case the wakeup did not happen, while it was in the past with F8
I'll CC Karel Zak, the maintainer of rtcwake, maybe he has something to say.
I think the problem is a wrong default mode in rtcwake(1). The mode has to be
"standby". See upstream patch (already in F10):
I'll backport the patch to F9 ASAP.
Karel, are you sure about the default mode?
Because I used "rtcwake -s 30 -m disk", and actually the machines go into S2D
The issue is that of 3 different HW, with F9, only the old P-III wakes up later.
On the other hand, on the very same HW (2 of the 3 types), using
/proc/acpi/alarm to define the wakeup and poweroff or S2D, works fine.
So, either rtcwake sets the wakeup not properly, or the kernel does some
unwanted clear/reset on shutdown.
Hope this helps.
OK, I got another PC with F9 and also this one does not wake up.
With "rtcwake -s 30 -m disk" it goes in S2D, but it never comes back.
One thing on this machine is that the BIOS offer some RTC wakeup alarm
configuration option, which is disabled.
Once enabled in BIOS, the rtcwake succeed.
The other intel PCs do not seem to have a BIOS option to control the RTC wakeup
I tried to enable the RTC wakeup alarm in the BIOS of the 64 bit machine.
In this case it is under the APM menu...
Unfortunately it does not seem to change a bit, rtcwake can put the machine to
sleep (S4, S5), but then this does not wake up.
(In reply to comment #3)
> I think the problem is a wrong default mode in rtcwake(1). The mode has to be
You are right. This is nonsense. Sorry.
OK, the machine with the BIOS option, while working with "rtcwake", i.e.
suspending and waking up, has the bad habit to also wake up at 00:00.00, each day.
I guess the reason is the BIOS somehow fixes the wakeup by its own to this time,
which is, of course, changeable in the BIOS.
I could not find any way to disable this, while keeping the RTC wakeup feature
In other words, unless something new is discovered, the RTC wakeup does not work
properly also on this machine.
I assign the issue back to the kernel component.
I can confirm that "rtcwake -s 30 -m mem" doesn't work on my x61. The machine
does not wake up...
I didn't found a problem in rtcwake, it seems this tool sets RTC_WKALM_SET ioctl
.. I forgot some details:
$ uname -a
Linux nb 22.214.171.124-76.fc9.x86_64 #1 SMP Fri Jun 27 15:58:30 EDT 2008 x86_64
x86_64 x86_64 GNU/Linux
# cat /proc/driver/rtc
rtc_time : 20:10:48
rtc_date : 2008-07-10
alrm_time : 12:36:42
alrm_date : ****-**-**
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
# cat /sys/class/rtc/rtc0/device/id
So, I tried to set the wakeup alarm using directly the sysfs interface:
Specifically I tried something like the following:
echo $[ $( cat /sys/class/rtc/rtc0/since_epoch ) + 30 ] >
/sys/class/rtc/rtc0/wakealarm ; echo disk > /sys/power/state
This sets the wakeup 30 seconds after the current time and then it performs an S2D.
This works, the machine goes into S2D and then it wakes up, exactly 30 seconds
after the command is issued.
I also tried S2R (echo mem > /sys/power/state) and "poweroff".
Both worked on the machine supporting this two power states.
It seems to me that something is not correct between "rtcwake" and the used ioctl.
For example, the /sys/class/rtc/rtc0/wakealarm interface requires the time in
second since epoch, maybe "rtcwake" or the ioctl have some problems with that.
Hope this helps,
Feedback from David:
On Fri, Jul 11, 2008 at 01:15:54AM -0700, David Brownell wrote:
> On Thursday 10 July 2008, you wrote:
> > Hi David,
> > please, read:
> > https://bugzilla.redhat.com/show_bug.cgi?id=449738
> > it seem some machines (include my x61) have problem wake up. Is it HW
> > problem or kernel problem? It seem that rtcwake(8) sets all ioctls
> > correctly.
> Does it work from S1 or S3 on the relevant machines?
> Does enabling/disabling HPET help?
> My guess is that this relates to ACPI. There's oddness
> in the ACPI interactions with RTCs, as well as how it
> handles suspend/resume, and HPET... and I've observed
> various changes to the ACPI messaging in that area in
> recent kernels, suggesting to me that the code has changed
> along with it. (There's at least one hardware variance
> that ACPI allows, which doesn't seem to show up on any
> hardware I have access to: RTC alarms can be reported
> at least two different ways.
> It'd be worth verifying that current (2.6.26-rc9) code
> still has this problem. If it does, then it's a case
> of looking at what the ACPI-to-RTC bindings are doing.
(In reply to comment #11)
> So, I tried to set the wakeup alarm using directly the sysfs interface
Good idea. I can confirm that:
# date -u -d "15sec" "+%s" > /sys/class/rtc/rtc0/wakealarm
# echo "mem" > /sys/power/state
# rtcwake --mode=mem --seconds=15
does not wake up at all.
Note, my x61 does not support S1 and S4 ("disk") does not suspend correctly (it
correctly freezes kernel+processes, but does not halt the machine. So I see
reboot after echo "disk" > /sys/power/state).
The kernel 2.6.26-136.fc10.x86_64 has the same problem (RTC_WKALM_SET does not
wakeup, setting by /sys/class/rtc/rtc0/wakealarm works).
# strace rtcwake strace rtcwake --mode=mem --seconds=15
... it uses RTC_ALM_SET and RTC_AIE_ON instead RTC_WKALM_SET.
The RTC_WKALM_SET works for me.
(In reply to comment #15)
> # strace rtcwake strace rtcwake --mode=mem --seconds=15
> ... it uses RTC_ALM_SET and RTC_AIE_ON instead RTC_WKALM_SET.
> The RTC_WKALM_SET works for me.
Interesting, this means the issue goes back to util-linux-ng...
Since I'm at it, I'll add also David (Brownell) CC here, so we keep everything
Hope it is not a problem.
Any idea on a possible fix?
BTW, I also re-assign the issue to the owner of util-linux-ng, since the kernel
does not seem to be the culprit, maybe better like this.
And finally (sigh!) I think I can set "Severity" to "Medium", since there is a
workaround (direct use of the sysfs interface).
Fixed in F9.
util-linux-ng-2.13.1-8.3.fc9 has been submitted as an update for Fedora 9
util-linux-ng-2.13.1-8.3.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.