[GUTSY] RTC alarm does not retain setting from /proc/acpi/alarm

[Fisslefink]

Binary package hint: linux-source-2.6.22

Ubuntu version: Kubuntu Gutsy (development) ... last upgraded 9/16/2007
Kernel version: 2.6.22-11-386
Motherboard: ASUS P4P800E-Deluxe
BIOS RTC Alarm Setting: Disabled
First broken: This worked fine with Feisty and kernel 2.6.20-13-386. It broke upon dist-upgrading to Gutsy.

Problem:

I have a file on my system called /home/mythtv/timestamp that gets updated with the preferred wakeup time of the system. The contents of the file are the following:

$ cat /home/mythtv/timestamp
2007-09-15 09:53:59

The command below is issued by a script, and it copies the wakeup time to the BIOS.

sudo sh -c 'cat /home/mythtv/timestamp > /proc/acpi/alarm'

Double-checking this reveals that the time is set correctly BEFORE shutdown:

$ cat /proc/acpi/alarm
2007-09-15 09:26:59

After shutting down the computer, it does not wake at the schedule time. When it is turned back on, the day is set to '00' in /proc/acpi/alarm, as shown below:

$ cat /proc/acpi/alarm
2007-09-00 09:26:59

This is presumably the cause of the alarm failure.

Troubleshooting attempts:

-- None of the suggestions at http://www.mythtv.org/wiki/index.php/ACPI_Wakeup have worked to resolve the issue.

-- There is an interesting comment on that page under the heading " Kernel 2.6.22+ and /sys/class/rtc/rtc0/wakealarm" that suggests this feature broke with Kernel 2.6.22, but the proposed fix only works for Fedora Core 7 users (Gutsy does not have the file "/sys/class/rtc/rtc0/wakealarm")

-- A similar bug is discussed here, but my bug occurs after a full power off: http://www.nabble.com/Real-Time-Clock-Alarm-Broken-with-2.6.22+-kernel-t4401170s15552.html and reported here: http://bugzilla.kernel.org/show_bug.cgi?id=899

A solution is proposed on the kernel.org bugzilla by 'rafael', but I do not have the skills needed to test it, and it sounds hibernation-specific:

>I think the suspend/hibernation code ordering changes after 2.6.20 are to blame
>here.
>
>Reportedly, the problem can be fixed by applying the patch from
>http://lkml.org/lkml/2007/8/27/392 , but that requires some other changes which
>are not present in 2.6.22.
>
>It would be nice if that could be tested on 2.6.23-rc5 with the patchset from
>http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.23-rc5/patches/ applied
>and the patch from http://lkml.org/lkml/2007/8/27/392 on top of it.
>
>Greetings,
>Rafael

-- MahoneyR has the same symptoms as described in this thread: http://ubuntuforums.org/showthread.php?t=349062 But the solution appears to be restarting the computer immediately after the next boot -- this was not needed with Feisty on my system and should not be needed now!

I'd be happy to provide more files and logs if they will help. Just PM "Fisslefink" on the ubuntuforums.

[Leann Ogasawara (leannogasawara)]

Hi,

Just curious if this was still an issue in the official 7.10 Gutsy Gibbon release (kernel 2.6.22-14)? If so, the Hardy Heron kernel was recently uploaded for testing. We'd really appreciate it if you could try testing with this newer kernel and verify if this issue still exists. Unfortunately, the Hardy Heron Alpha1 LiveCD was released with the older 2.6.22 kernel. You'll have to manually install the newer Hardy Heron kernel in order to test. This should not be the case for Alpha2 which is set to come out around Dec 20. However, here are the instructions to install if you choose to do so, otherwise just wait for Alpha2 to come out:

1) edit the file /etc/apt/sources.list and add the following line:

deb http://archive.ubuntu.com/ubuntu hardy main restricted

2) sudo apt-get update
3) sudo apt-get install linux-image-2.6.24-1-generic
4) reboot and select the new kernel from the grub menu

After you've tested, please feel free to revert back - ie boot into the old kernel, sudo apt-get remove linux-image-2.6.24-1-generic, and remove the line from /etc/apt/sources.list . Please update this report with your results. Thanks in advance!

[Andreas Fey (info-andreas-fey)]

Same problem to me with Ubuntu 7.10. Before the update from Feisty everything worked like a charm, but immediately after the update i can write the wakeup time a thousand times to /proc/acpi/alarm, use or don't use the poweroff - kernel, the machine sleeps forever.

@Leann:
Even the new kernel from hardy did not work - i tested it exactly the way you described.

[Leann Ogasawara (leannogasawara)]

Thanks for testing and providing and update. Per the kernel team's bug policy, can you please attach the following information when running the newer kernel:

* uname -a > uname-a.log
* cat /proc/version_signature > version.log
* dmesg > dmesg.log
* sudo lspci -vvnn > lspci-vvnn.log

Please be sure to attach each file as a separate attachment. For more information regarding the kernel team bug policy, please refer to https://wiki.ubuntu.com/KernelTeamBugPolicies . Thanks again and we appreciate your help and feedback.

[Leann Ogasawara (leannogasawara)]

A new task is open against the actively developed kernel. However, against the linux-source-2.6.22 task, this report does not meet the criteria for a stable release update and will be closed. You can learn more about the stable release update process at https://wiki.ubuntu.com/StableReleaseUpdates . Thanks!

[Milan Knizek (knizek)]

I can confirm the same bug for ASUS P5LD2 Deluxe motherboard in Ubuntu 7.10 and 8.04 alpha 3.

In 7.10, the file /proc/acpi/alarm shows 00 in place of a date in month (like described above) after reboot.

In 8.04 alpha 3, the file is missing at all. According to mythtv wiki, the /proc/acpi/alarm should be replaced by /sys/class/rtc/rtc0/wakealarm however the directory /sys/class/rtc/ is emtpy. I am not sure if it relates - in dmesg there is a message "unable to open rtc device (rtc0)" from /drivers/rtc/hctosys.c (both in 7.10 and 8.04 alpha 3).

[Milan Knizek (knizek)]

I was finally able to solve the problem. According to http://www.mythtv.org/wiki/index.php/ACPI_Wakeup I had to change the /etc/init.d/hwclock.sh as follows:

...
       stop|restart|reload|force-reload)

==> ACPITIME=`cat /proc/acpi/alarm`
                if [ "$HWCLOCKACCESS" != no ]
                then
                    if [ "$VERBOSE" != no ]
                    then
                        echo "Saving the System Clock time to the Hardware Clock..."
                    fi
                    [ "$GMT" = "-u" ] && GMT="--utc"
                        /sbin/hwclock --systohc $GMT $BADYEAR
                    if [ "$VERBOSE" != no ]
                    then
                        echo "Hardware Clock updated to `date`."
                    fi
==> echo "$ACPITIME" > /proc/acpi/alarm

The explanation is that altering the hw clock during shutdown disables the RTC alarm in some BIOSes. I will file this bug to util-linux package.

[Connor Imes (ckimes)]

Fisslefink,
Thank you for taking the time to report this bug and helping to make Ubuntu better. You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering is this still an issue for you? Can you try with latest Ubuntu release? Thanks in advance.

[Leann Ogasawara (leannogasawara)]

The Ubuntu Kernel Team is planning to move to the 2.6.27 kernel for the upcoming Intrepid Ibex 8.10 release. As a result, the kernel team would appreciate it if you could please test this newer 2.6.27 Ubuntu kernel. There are one of two ways you should be able to test:

1) If you are comfortable installing packages on your own, the linux-image-2.6.27-* package is currently available for you to install and test.

--or--

2) The upcoming Alpha5 for Intrepid Ibex 8.10 will contain this newer 2.6.27 Ubuntu kernel. Alpha5 is set to be released Thursday Sept 4. Please watch http://www.ubuntu.com/testing for Alpha5 to be announced. You should then be able to test via a LiveCD.

Please let us know immediately if this newer 2.6.27 kernel resolves the bug reported here or if the issue remains. More importantly, please open a new bug report for each new bug/regression introduced by the 2.6.27 kernel and tag the bug report with 'linux-2.6.27'. Also, please specifically note if the issue does or does not appear in the 2.6.26 kernel. Thanks again, we really appreicate your help and feedback.

[Karel Marik (kaja-marik)]

I just experienced similar problem with acpi wakeup. I followed steps found on http://www.mythtv.org/wiki/index.php/ACPI_Wakeup:

1) set alarm timestamp
$ sudo sh -c 'echo "+00-00-00 00:05:00" > /proc/acpi/alarm'

2) checked
$ cat /proc/acpi/alarm
2008-09-20 14:56:33

3) shutdown
$ sudo shutdown -h -P now

However, computer didn't start at given time. I entered BIOS UI and found the problem is in wake-up date which was not set to 20 (day of month) but remained unchanged =1. Wake-up time was set correctly. When I manually changed wake-up date and repeated procedure then computer started as expected. I tried to resolve this issue by updating BIOS version but without success.

System: 8.04 (hardy), kernel 2.6.24-19-generic
Motherboard: Asus A7V8X-X, tested BIOS versions - 8 and 11

I'd be happy to provide more files and logs if they will help.

[Leann Ogasawara (leannogasawara)]

Hi Karl,

Could you test the more recent 2.6.27 kernel available in Intrepid? Or even the 2.6.28 based kernel which will be available in the upcoming Jaunty release - http://cdimage.ubuntu.com/releases/jaunty/ . I think they provide a newer interface to use - /sys/class/rtc/rtc0/wakealarm . Note that wakealarm uses absolute time in seconds (date + %s). Please let us know your results. Thanks.

[Fisslefink (erin-simonds)]

I had experienced this bug with Gutsy and Hardy. It started working again
with Intrepid. I currently use it all the time... I have kernel
"2.6.27-7-generic #1 SMP Tue Nov 4 19:33:20 UTC 2008 i686 GNU/Linux" My
motherboard is an Asus P4P800-E Deluxe

I use the script below, called "MythWakeSet". Note that it clears the RTC
before writing to it.

#!/bin/bash

echo 0 > /sys/class/rtc/rtc0/wakealarm
echo $1 > /sys/class/rtc/rtc0/wakealarm

readabledate=`perl -e '$date=localtime('$1'); print $date;'`
echo "Next Wakeup will be at $readabledate"

exit 0

Usage:
MythWakeSet [time in epoch]

Example:
./MythWakeSet 1232075790

Output:
Next Wakeup will be at Thu Jan 15 19:16:30 2009

On Thu, Jan 15, 2009 at 5:51 PM, Leann Ogasawara <
<email address hidden>> wrote:

> Hi Karl,
>
> Could you test the more recent 2.6.27 kernel available in Intrepid? Or
> even the 2.6.28 based kernel which will be available in the upcoming
> Jaunty release - http://cdimage.ubuntu.com/releases/jaunty/ . I think
> they provide a newer interface to use - /sys/class/rtc/rtc0/wakealarm .
> Note that wakealarm uses absolute time in seconds (date + %s). Please
> let us know your results. Thanks.
>
> --
> [GUTSY] RTC alarm does not retain setting from /proc/acpi/alarm
> https://bugs.launchpad.net/bugs/139846
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[Karel Marik (kaja-marik)]

I repeated my tests just after I installed Intrepid. Here are my results:
1) echo 0 > /sys/class/rtc/rtc0/wakealarm
doesn't work due to Permission denied error

2) I found workaround :
username@comp:~$ sudo sh -c 'echo 0 > /sys/class/rtc/rtc0/wakealarm'
username@comp:~$ sudo sh -c 'echo `date "+%s" -d "+ 5 minutes"` > /sys/class/rtc/rtc0/wakealarm'
username@comp:~$ cat /sys/class/rtc/rtc0/wakealarm
username@comp:~$ cat /proc/driver/rtc
rtc_time : 23:20:51
rtc_date : 2009-01-21
alrm_time : 23:25:29
alrm_date : ****-**-21
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
username@comp:~$

It is interesting "cat /sys/class/rtc/rtc0/wakealarm" gives no output.

Computer didn't boot at specified time. Manual inspection of BIOS setting revealed correctly changed time (23:25:29). However date (of month) was wrong - 1.

3) I repeated step 2 with changed /etc/default/rcS file according to advice in http://www.mythtv.org/wiki/ACPI_Wakeup

Same result as in (2) in BIOS. Warning! I had serious problem to boot then! Finally, I had to boot using live CD and reject changes in /etc/default/rcS in order to boot again.

I am strongly interested to turn it working. So far without success. I am planning to test Fisslefink's solution next time.

Regards

Karel

[Fisslefink (erin-simonds)]

Karel,

I think in your "workaround" you have effectively tried the steps that my
script accomplishes (echo 0, echo time_t), and I'm sorry to hear that did
not work for you. It is possible that I got it working through some
additional trick, which I have now forgotten. I'll see if a fresh
installation of Intrepid on my system works as I claimed above.

Fisslefink

On Wed, Jan 21, 2009 at 3:10 PM, Karel Marik <email address hidden> wrote:

> I repeated my tests just after I installed Intrepid. Here are my results:
> 1) echo 0 > /sys/class/rtc/rtc0/wakealarm
> doesn't work due to Permission denied error
>
> 2) I found workaround :
> username@comp:~$ sudo sh -c 'echo 0 > /sys/class/rtc/rtc0/wakealarm'
> username@comp:~$ sudo sh -c 'echo `date "+%s" -d "+ 5 minutes"` >
> /sys/class/rtc/rtc0/wakealarm'
> username@comp:~$ cat /sys/class/rtc/rtc0/wakealarm
> username@comp:~$ cat /proc/driver/rtc
> rtc_time : 23:20:51
> rtc_date : 2009-01-21
> alrm_time : 23:25:29
> alrm_date : ****-**-21
> 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
> username@comp:~$
>
> It is interesting "cat /sys/class/rtc/rtc0/wakealarm" gives no output.
>
> Computer didn't boot at specified time. Manual inspection of BIOS
> setting revealed correctly changed time (23:25:29). However date (of
> month) was wrong - 1.
>
> 3) I repeated step 2 with changed /etc/default/rcS file according to
> advice in http://www.mythtv.org/wiki/ACPI_Wakeup
>
> Same result as in (2) in BIOS. Warning! I had serious problem to boot
> then! Finally, I had to boot using live CD and reject changes in
> /etc/default/rcS in order to boot again.
>
> I am strongly interested to turn it working. So far without success. I
> am planning to test Fisslefink's solution next time.
>
> Regards
>
> Karel
>
> --
> [GUTSY] RTC alarm does not retain setting from /proc/acpi/alarm
> https://bugs.launchpad.net/bugs/139846
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[Fisslefink (erin-simonds)]

For what it's worth, here is the result of "cat /proc/driver/rtc" on my
system:

mythtv@mythtv-ibex:~$ cat /proc/driver/rtc
rtc_time : 00:03:51
rtc_date : 2009-01-22
alrm_time : 02:25:00
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

Fisslefink

On Wed, Jan 21, 2009 at 4:03 PM, Erin Simonds <email address hidden>wrote:

> Karel,
>
> I think in your "workaround" you have effectively tried the steps that my
> script accomplishes (echo 0, echo time_t), and I'm sorry to hear that did
> not work for you. It is possible that I got it working through some
> additional trick, which I have now forgotten. I'll see if a fresh
> installation of Intrepid on my system works as I claimed above.
>
> Fisslefink
>
>
>
>
> On Wed, Jan 21, 2009 at 3:10 PM, Karel Marik <email address hidden> wrote:
>
>> I repeated my tests just after I installed Intrepid. Here are my results:
>> 1) echo 0 > /sys/class/rtc/rtc0/wakealarm
>> doesn't work due to Permission denied error
>>
>> 2) I found workaround :
>> username@comp:~$ sudo sh -c 'echo 0 > /sys/class/rtc/rtc0/wakealarm'
>> username@comp:~$ sudo sh -c 'echo `date "+%s" -d "+ 5 minutes"` >
>> /sys/class/rtc/rtc0/wakealarm'
>> username@comp:~$ cat /sys/class/rtc/rtc0/wakealarm
>> username@comp:~$ cat /proc/driver/rtc
>> rtc_time : 23:20:51
>> rtc_date : 2009-01-21
>> alrm_time : 23:25:29
>> alrm_date : ****-**-21
>> 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
>> username@comp:~$
>>
>> It is interesting "cat /sys/class/rtc/rtc0/wakealarm" gives no output.
>>
>> Computer didn't boot at specified time. Manual inspection of BIOS
>> setting revealed correctly changed time (23:25:29). However date (of
>> month) was wrong - 1.
>>
>> 3) I repeated step 2 with changed /etc/default/rcS file according to
>> advice in http://www.mythtv.org/wiki/ACPI_Wakeup
>>
>> Same result as in (2) in BIOS. Warning! I had serious problem to boot
>> then! Finally, I had to boot using live CD and reject changes in
>> /etc/default/rcS in order to boot again.
>>
>> I am strongly interested to turn it working. So far without success. I
>> am planning to test Fisslefink's solution next time.
>>
>> Regards
>>
>> Karel
>>
>> --
>> [GUTSY] RTC alarm does not retain setting from /proc/acpi/alarm
>> https://bugs.launchpad.net/bugs/139846
>> You received this bug notification because you are a direct subscriber
>> of the bug.
>>
>
>

[Karel Marik (kaja-marik)]

I tested wakealarm with changed BIOS setting. I set PowerUp method to "Everyday" instead of "ByDate". Then applied same procedure:
$ sudo sh -c 'echo 0 > /sys/class/rtc/rtc0/wakealarm'
$ sudo sh -c 'echo `date "+%s" -d "+ 5 minutes"` > /sys/class/rtc/rtc0/wakealarm'

Computer woke up after 5 minutes normally. Thus, time setting is correct. The whole problem is to set date.

Fisslefink, could you please post your BIOS setting?
Next item - there is significant difference between my and your cat /proc/driver/rtc listing in alarm date. Your alarm date is set to "****-**-**". Mine alarm date shows day of month. Could you please verify if your generated cat /proc/driver/rtc just after setting alarm? Thank you.

Leann, is there any way to test Jaunty wakeup without installing it? (e.g. using just from live CD or using a virtual image?) It took me lot of time to setup current installation. :)

Karel
2.6.27-9-generic
Mobo: Asus A7V8X-X

[Fisslefink (erin-simonds)]

In response to Karel's question about the date setting. If the alarm is
set, and the computer is rebooted manually, then "cat /proc/driver/rtc"
shows the following:

rtc_time : 22:18:23
rtc_date : 2009-01-22
alrm_time : 02:25:00
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

If the alarm is changed manually, then "cat /proc/driver/rtc" shows the new
alrm_date correctly until the next reboot:

rtc_time : 22:19:29
rtc_date : 2009-01-22
alrm_time : 22:24:22
alrm_date : 2009-01-22
alarm_IRQ : yes
alrm_pending : no
24hr : yes
periodic_IRQ : no
update_IRQ : no
HPET_emulated : yes
DST_enable : no
periodic_freq : 1024

However, upon rebooting, it will again show "****-**-**" for alrm_date.
This does not prevent the alarm from working correctly -- it does indeed
wake up at the intended time, but I believe it is no longer specific for the
date. This could be considered a bug, but I cannot rule out that it simply
a limitation of the BIOS.

For what it's worth, this behavior is not a problem for me -- I don't mind
if the computer wakes up at 9am every day, since I have set it to go to
sleep after 5 minutes of inactivity.

Fisslefink

On Thu, Jan 22, 2009 at 2:02 PM, Karel Marik <email address hidden> wrote:

> I tested wakealarm with changed BIOS setting. I set PowerUp method to
> "Everyday" instead of "ByDate". Then applied same procedure:
> $ sudo sh -c 'echo 0 > /sys/class/rtc/rtc0/wakealarm'
> $ sudo sh -c 'echo `date "+%s" -d "+ 5 minutes"` >
> /sys/class/rtc/rtc0/wakealarm'
>
> Computer woke up after 5 minutes normally. Thus, time setting is
> correct. The whole problem is to set date.
>
> Fisslefink, could you please post your BIOS setting?
> Next item - there is significant difference between my and your cat
> /proc/driver/rtc listing in alarm date. Your alarm date is set to
> "****-**-**". Mine alarm date shows day of month. Could you please verify if
> your generated cat /proc/driver/rtc just after setting alarm? Thank you.
>
> Leann, is there any way to test Jaunty wakeup without installing it?
> (e.g. using just from live CD or using a virtual image?) It took me lot
> of time to setup current installation. :)
>
> Karel
> 2.6.27-9-generic
> Mobo: Asus A7V8X-X
>
> --
> [GUTSY] RTC alarm does not retain setting from /proc/acpi/alarm
> https://bugs.launchpad.net/bugs/139846
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[Leann Ogasawara (leannogasawara)]

Fisslefink, since you are the original bug reporter and confirm this is no longer an issue, I'm marking this Fix Released. Karl, it may be the issue you are seeing is related to a known upstream bug http://bugzilla.kernel.org/show_bug.cgi?id=12013 . Thanks.