Bug 449738 - Wakeup on RTC alarm does not work anymore
Summary: Wakeup on RTC alarm does not work anymore
Alias: None
Product: Fedora
Classification: Fedora
Component: util-linux-ng
Version: 9
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Karel Zak
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2008-06-03 09:50 UTC by Piergiorgio Sartor
Modified: 2008-09-10 07:11 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2008-09-10 07:11:37 UTC
Type: ---

Attachments (Terms of Use)

Description Piergiorgio Sartor 2008-06-03 09:50:04 UTC
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):

How reproducible:

Steps to Reproduce:
rtcwake -s 30 -m disk
Actual results:
The P-III wakes up without problems, the P4 does not wakeup... Never...

Expected results:
The P4 should wake up.

Additional info:
The F8 kernel is
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.


Comment 1 Piergiorgio Sartor 2008-06-03 13:04:51 UTC
Short update.
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.


Comment 2 Piergiorgio Sartor 2008-06-12 08:26:23 UTC
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
and /proc/acpi/alarm.

I'll CC Karel Zak, the maintainer of rtcwake, maybe he has something to say.


Comment 3 Karel Zak 2008-06-12 13:30:02 UTC
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.

Comment 4 Piergiorgio Sartor 2008-06-12 15:31:37 UTC
Karel, are you sure about the default mode?

Because I used "rtcwake -s 30 -m disk", and actually the machines go into S2D
without problems.

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.


Comment 5 Piergiorgio Sartor 2008-07-07 15:47:23 UTC
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


Comment 6 Piergiorgio Sartor 2008-07-07 18:09:46 UTC
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.


Comment 7 Karel Zak 2008-07-10 12:44:30 UTC
(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.

Comment 8 Piergiorgio Sartor 2008-07-10 13:42:22 UTC
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
with "rtcwake".

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.


Comment 9 Karel Zak 2008-07-10 20:01:47 UTC
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

Comment 10 Karel Zak 2008-07-10 20:15:02 UTC
.. I forgot some details:

$ uname -a
Linux nb #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

Comment 11 Piergiorgio Sartor 2008-07-14 18:04:12 UTC
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,


Comment 12 Karel Zak 2008-07-15 11:42:17 UTC
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.

Comment 13 Karel Zak 2008-07-15 11:51:28 UTC
(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

works, and

 # 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).


Comment 14 Karel Zak 2008-07-15 12:03:21 UTC
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).

Comment 15 Karel Zak 2008-07-15 12:59:48 UTC

 # 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.

Comment 16 Piergiorgio Sartor 2008-07-15 14:27:56 UTC
(In reply to comment #15)
> Ah... 
>  # 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?


Comment 17 Piergiorgio Sartor 2008-07-15 14:33:03 UTC
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.


Comment 18 Piergiorgio Sartor 2008-07-15 14:36:16 UTC
And finally (sigh!) I think I can set "Severity" to "Medium", since there is a
workaround (direct use of the sysfs interface).


Comment 19 Karel Zak 2008-08-12 14:08:40 UTC
Fixed in F9.

Comment 20 Fedora Update System 2008-08-12 20:08:53 UTC
util-linux-ng-2.13.1-8.3.fc9 has been submitted as an update for Fedora 9

Comment 21 Fedora Update System 2008-09-10 07:11:28 UTC
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.

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