Most recent kernel where this bug did not occur: Distribution: Fedora core 3 with Kernel 2.6.14 with swsusp2 added Hardware Environment: Fujitsu S6231 laptop Software Environment: Problem Description: Setting the alarm is not working properly. All the problems here come from drivers/acpi/sleep/proc.c For exemple, the following should set the alarm 9 min in the future but instead it just adds 3min [root@tunnel ~]# date;echo "+0-0-0 0:9:0" >/proc/acpi/alarm Thu Jan 5 02:47:02 EST 2006 [root@tunnel ~]# cat /proc/acpi/alarm 0006-01-05 02:50:03 If I hibernate, a century of 0 is detected as an error by my BIOS when I reboot and the date is reinitialized to Jan 1, 1988. The problem is that the addition is done on BCD numbers. Because of the way the conversion is defined the addition breaks down for any hexadecimal carry, i.e. 8+7=15=0xf will work but 8+8=16=x10 produces the kind of problem above (9+7=16). Also the code incorrectly reads the year with century and worst it sets it. As seen above the year is now 0006. This is because the century is incorrectly calculated but also it is not necessary/usefull to set it for the alarm. I would see this more related to the rtc driver or to have its own interface (currently the drivers/char/rtc does not seem to use the century values but does its own century calculation therefore acpi and rtc can have different ideas of the current year). The user interface should be improved to also show the active elements of the alarm. On my machine only the day is available, not the month. And from the ACPI spec I guess the year is never available. Maybe the inactive field could be replaced by xx or not shown at all. BTW the century value should follow the same BCD conversion as the other values. Here the code luckilly works for 200? years but fails miserably for 19?? years. For exemple with the year set to 1988 in the BIOS, the acpi alarm reports the year as 1652 (after a reboot). Finally, months are assumed to be 31 days for wrap around calculation. Obviously this is not valid all the time. I checked the kernel patch for 2.6.15 and I believe nothing as changed there so the problems there will be the same (but I have not tested it).
Created attachment 6966 [details] patch of drivers/acpi/sleep/proc.c to fix/improve alarm I changed the drivers/acpi/sleep/proc.c code related to the alarm to fix/improve what I described in the bug report. With this patch, cat /proc/acpi/alarm prints (on my machine) ****-**-00 01:04:00 -int (2006-01-07 23:08:52) On my machine only the day is setable not the month for the alarm. Anything not setable is replaced by *. The -int says the interupt is currently disabled. When an alarm is set it shows +int. In parathensis it shows the rtc current date/time (including correct century). To set the alarm, it works as before: echo "0000-00-02 1:0:0" >/proc/acpi/alarm sets the alarm for the second of the month at 1am. echo "+0000-00-00 1:0:0" >/proc/acpi/alarm sets the alarm in 1 hour. And I added the following: echo "-" >/proc/acpi/alarm which disables the currently set alarm. BTW setting a day or month of 0 is valid, the RTC clock uses that to skip month or day detection. Therefore an alarm of 0000-00-00 1:0:0 will be activated any day of the month at 1 am. It is possible to have a similar effect for hour/min/sec but I did not implement it (need to write something like 0xff to cmos). I tested the patch, but not fully since my machine does not have month.
Looks great! Thanks for the patch! One minor comment: why did you not show/set the centry alarm if the system supports the feature?
I show the century in the current date between parenthesis. I do not set the century because it is not an alarm (there is no year alarm and some machine, like mine, don't even have month alarm). It is the century part of the rtc date. It could be set in the main kernel rtc clock or it could be set in an acpi interface to set the current rtc date/time. I almost added a /proc/acpi/date that would show/set the current date/time including the century but that meant repeating the code already in the main kernel rtc so I did not. Eventually it could be a good idea (maybe when full handlers to the cmos extensions are added).
haha, I understand. Great! I'll mark this one as resolved, so Len Brown will merge this patch. Thanks!
Upon 2.6.21, the rtc-sysfs creates /sys/class/rtc which is going to replace /proc/acpi/alarm. So we should not enhance the parsing for /proc/acpi/alarm, as is is going to be deleted in the forseeable future. Instead, any efforts here should be focused on the new generic rtc code. closed.
Len, why is this bug reopened? thanks, rui
we allowed some fixes to /proc/acpi/ recently, and shaohua suggested if we did that then we should re-examine this one.
I think this bug can be closed if Yakui's patch hits linus tree.
The following commit is added to linus tree. >commit c116bc2ae516e9949d645bc75b1ee294ff15db23 >Author: Zhao Yakui <yakui.zhao@intel.com> >Date: Mon Apr 28 02:11:58 2008 -0700 > rtc: add the support for alarm time relative to current time in sysfs So the bug will be marked as the resovled.