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 "rtcwake"). This seems *not* to work properly. Version-Release number of selected component (if applicable): 2.6.25.3-18.fc9.i686 How reproducible: Always Steps to Reproduce: 1. rtcwake -s 30 -m disk 2. wait... 3. 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 2.6.24.7-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. Thanks!
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. pg
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. pg
I think the problem is a wrong default mode in rtcwake(1). The mode has to be "standby". See upstream patch (already in F10): http://git.kernel.org/?p=utils/util-linux-ng/util-linux-ng.git;a=commitdiff;h=47bf8ef7f1d084befe2efcdd37a5f7c7c9d9da70 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 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. pg
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 alarm. pg
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. pg
(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 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. pg
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 correctly.
.. I forgot some details: $ uname -a Linux nb 2.6.25.9-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 PNP0b00
So, I tried to set the wakeup alarm using directly the sysfs interface: /sys/class/rtc/rtc0/wakealarm 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, pg
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 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). [kernel-2.6.25.9-76.fc9.x86_64]
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).
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.
(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 together. Hope it is not a problem. Any idea on a possible fix? pg
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. pg
And finally (sigh!) I think I can set "Severity" to "Medium", since there is a workaround (direct use of the sysfs interface). pg
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.