Latest working kernel version: 2.6.26-rc5 Earliest failing kernel version: 2.6.26-rc6 Distribution: Debian Etch with some packages from Lenny Hardware Environment: Gigabyte GA-6OXM7 (RTC can wake from S4, alarms up to one month) 00:00.0 Host bridge: Intel Corporation 82815 815 Chipset Host Bridge and Memory Controller Hub (rev 02) 00:02.0 VGA compatible controller: Intel Corporation 82815 CGC [Chipset Graphics Controller] (rev 02) 00:1e.0 PCI bridge: Intel Corporation 82801AA PCI Bridge (rev 02) 00:1f.0 ISA bridge: Intel Corporation 82801AA ISA Bridge (LPC) (rev 02) 00:1f.1 IDE interface: Intel Corporation 82801AA IDE (rev 02) 01:04.0 Network controller: RaLink RT2561/RT61 802.11g PCI 01:05.0 Ethernet controller: Intel Corporation 82545GM Gigabit Ethernet Controller (rev 04) 01:08.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) 01:0a.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) Software Environment: Video Disk Recorder (VDR) Problem Description: After setting the wakeup time via /sys/class/rtc/rtc0/wakealarm, the system does'nt wake up anymore. RTC runs in UTC, RTC wakeup is enabled in BIOS. Git bisect figured out that e1094bfa26e5e94af2fea79e004614dbce42b008 (ACPI: Disable Fixed_RTC event when installing RTC handler) caused this regression. (See bug 10010) Steps to reproduce: echo 0 > /sys/class/rtc/rtc0/wakealarm date +%s -d "+4 minutes" > /sys/class/rtc/rtc0/wakealarm halt
Created attachment 17382 [details] Kernel configuration
Other users at VDR Portal (german board for VDR users, http://www.vdr-portal.de/board/thread.php?threadid=79457) reported the same issue with the following boards: MSI K8NGM2-FID ASUS M2A-VM HDMI
Hi, Stefan Thanks for the info and your efforts. Will you please try the latest kernel and see whether the problem still exists? From the description it seems that the bug is related with the following commit. >commit e1094bfa26e5e94af2fea79e004614dbce42b008 >ACPI: Disable Fixed_RTC event when installing RTC handler After the above commit is merged, the Fixed_RTC event will be disabled when installing RTC handler.Only when RTC alarm is set will it be enabled again. That is to say, whether the Fixed_RTC event is enabled depends on the user requirement. Will you please confirm whether your system can be waked up by RTC? It is noted that the system should enter the sleeping state(S3 or S4) after RTC alarm is set. It will be great if you can attach the output of acpidump. Thanks.
(In reply to comment #3) Thanks for your reply and hints! > Will you please try the latest kernel and see whether the problem still > exists? I tested 2.6.27-rc4 yesterday with negative result. > Will you please confirm whether your system can be waked up by RTC? The system itself can be waked up, the "steps to reproduce" in the description work with kernel 2.6.25 - the system shuts down and wakes up after 4 minutes. I like to emphazize the following: ACPI spec says, the system should not wake up from S5. But it does so until 2.6.25, which was good from our (VDR users) point of view; we use this to program timers for recording TV. I'm not shure, possibly "Disable Fixed_RTC event when installing RTC handler" 'fixed' this behaviour to be compliant to the spec, which is bad for us. > It is > noted that the system should enter the sleeping state(S3 or S4) after RTC > alarm > is set. echo 0 > /sys/class/rtc/rtc0/wakealarm date +%s -d "+10 minutes" > /sys/class/rtc/rtc0/wakealarm echo mem > /sys/power/state works as expected.
Created attachment 17398 [details] acpidump output
Created attachment 17400 [details] Patch against "ACPI: Disable Fixed_RTC event when installing RTC handler" This is a patch to make ACPI wakeup work again created by a guy called e9hack in VDR Portal. It is against commit e1094bfa26e5e94af2fea79e004614dbce42b008 and is tested positive by him and me. He likes to annotate the following: - It is not clear to us if the added calls of cmos->wake_on() and cmos->wake_off() should be inside rtc_lock or not - It is not clear to us if enable/disable_irq_wake() should be called if wake_on/off == NULL
For clarification, only the changes in cmos_set_alarm() have an effect. The shutdown function is never called on a shutdown. -Hartmut (e9hack)
Created attachment 17412 [details] Patch to test Incidentally, I've been looking into this recently. Stefan, can you try this patch, please?
Hi Rafael, I'm sorry, your patch doesn't work for me. 2.6.27-rc4 + your patch still isn't waking up from S5.
I've add the patch and some printk's to 2.6.26.3. On 'modprobe rtc_cmos' I get: cmos_init cmos_pnp_probe cmos_do_probe rtc_cmos 00:02: rtc core: registered rtc_cmos as rtc0 rtc0: alarms up to one year, y3k On 'rmmod rtc_cmos' I get: cmos_exit cmos_pnp_remove cmos_do_remove cmos_do_shutdown I've added a udelay loop of 20sec after the printk in cmos_exit. On a shutdown, I do not see the message or the 20sec gap before the PC is switched off. It seems, that cmos_exit is never called on a shutdown. This was the reason why I add the code to cmos_set_alarm().
(In reply to comment #4) > > echo 0 > /sys/class/rtc/rtc0/wakealarm > date +%s -d "+10 minutes" > /sys/class/rtc/rtc0/wakealarm > echo mem > /sys/power/state > > works as expected. > I'm a little confused. the bug sumary should be "RTC wakeup from S5 doesn't work anymore"? If yes, then it's the problem that e1094bfa26e5e94af2fea79e004614dbce42b008 tries to fix. :) RTC will be disabled by default, and it will be enabled only if 1. users set a RTC alarm. 2. cmos_suspend is called (before entering s3/s4) as it's not enabled before entering S5, RTC wakeup from s5 doesn't work. IMO, we should fix it in the current rtc-cmos code, which doesn't support runtime and s5 wakeup event (cmos_suspend will not be called in these cases). i.e. enable the RTC event once alarm is set, rather than before entering a sleep state. cc Dave. :)
(In reply to comment #11) > (In reply to comment #4) > > > > echo 0 > /sys/class/rtc/rtc0/wakealarm > > date +%s -d "+10 minutes" > /sys/class/rtc/rtc0/wakealarm > > echo mem > /sys/power/state > > > > works as expected. > > > I'm a little confused. > the bug sumary should be "RTC wakeup from S5 doesn't work anymore"? Yes, that's what I meant. Sorry for the bad summary, I'll change it.
(In reply to comment #9) > Hi Rafael, I'm sorry, your patch doesn't work for me. 2.6.27-rc4 + your patch > still isn't waking up from S5. OK, thanks for testing, I'll have to do some debugging. BTW, this patch is attempting to make cmos_suspend() be called before S5 as Zhang Rui said and I wonder what's wrong with it. Hartmut, cmos_platform_shutdown() is surely called during system shutdown, but of course it's not called while the module is unloaded.
Hmm. Stefan, please set CONFIG_HIBERNATION or CONFIG_SUSPEND and retest with the patch from Comment #8, thanks.
Scratch that, sorry, you have CONFIG_PM=y and that should be sufficient. I'll _really_ have to do some debugging.
Agree with what Rui said in comment #11. >RTC will be disabled by default, and it will be enabled only if >1. users set a RTC alarm. >2. cmos_suspend is called (before entering s3/s4) as it's not enabled before entering S5, RTC wakeup from s5 doesn't work. When the system enters the S5, the cmos_platform_shutdown will be called, in which the cmos_do_shutdown is called. But the RTC event is not enabled in the function of cmos_do_shutdown. If it is expected that the system can be waked by RTC from S5, IMO the RTC event should be enabled in the function of cmos_platform_shutdown if RTC alarm is set. Of course IMO it is also reasonable that the RTC event is enabled once the RTC alarm is set , rather than entering the sleeping state(S3/S4/S5). Thanks.
Created attachment 17449 [details] try the debug patch based on the patch in comment #8 Will you please try the debug patch and see whether the problem still exists? The debug patch is based on Rafael's patch in comment #8, in which cmos_pnp_shutdown is added for cmos pnp device. Thanks.
One reason rtc-cmos disables its alarm going into S5 -- actually, on all shutdown paths, including kexec -- is to avoid surprising whatever software runs next. Another is, as noted earlier, that the ACPI spec pretty much says that RTC won't wake from S5 ... not that I consider that important for Linux. :) Note that whatever is done with this, the fix should work ON TOP OF the patch from Bug #11153 comment 18 ... which had to work around a couple different bugs in ACPI event handling. Re comment #17 here ... does that even compile without warnings? It's using the shutdown method in "struct device" but provides a method which takes a PNP device instead of a (generic) device.
Created attachment 17455 [details] try the debug patch based on the patch in comment #8 Sorry that I attached the incorrect patch.(The input parameter in shutdown method should be "struct device" rather than PNP device.) Thank David Brownell for your helps.
(In reply to comment #19) > Created an attachment (id=17455) [details] > try the debug patch based on the patch in comment #8 As the Gigabyte board mentioned in description is currently unavailable to me, I tested your patch from comment 19 on an Asus A8V (which shows the same misbehavior - wakes from S5 with 2.6.25, not with 2.6.26). It doesn't work, sorry.
Did you apply the patch from Bug #11153 comment 18 as suggested by David?
(In reply to comment #21) > Did you apply the patch from Bug #11153 comment 18 as suggested by David? Yes, I tested with and without, neither works.
Is there anything in /sys/class/rtc/rtc0/power/wakeup on your system?
Sorry, in /sys/devices/pnp0/00:02/power/wakeup ?
(In reply to comment #24) > Sorry, in /sys/devices/pnp0/00:02/power/wakeup ? cat /sys/devices/pnp0/00\:02/power/wakeup enabled This is with kernel 2.6.25 on the Asus A8V. Do you need the output with any other kernel version?
(In reply to comment #19) > Created an attachment (id=17455) [details] > try the debug patch based on the patch in comment #8 The patch works on a MSI K8NGM2-FID with kernel 2.6.26.3 (compiled for x86_64). I've add some nice printk's to some functions and a 20sec udlay loop to cmos_suspend. On shutdown I get: cmos_pnp_shutdown cmos_poweroff cmos_suspend the 20sec gap two more lines (to fast for reading) PC is switched off
Stefan, no, that's fine. What's in /proc/driver/rtc ?
OK, the patch from Comment #19 works on my test box too.
Stefan, can you please do: # cat /proc/driver/rtc # date +%s -d "+4 minutes" > /sys/class/rtc/rtc0/wakealarm # cat /proc/driver/rtc and post the result?
(In reply to comment #29) > Stefan, can you please do: > > # cat /proc/driver/rtc > # date +%s -d "+4 minutes" > /sys/class/rtc/rtc0/wakealarm > # cat /proc/driver/rtc > > and post the result? This is 2.6.27-rc4 + bug 11153 comment 18 + bug 11411 comment 19 on Asus A8V, RTC runs localtime, RTC wakeup enabled in BIOS: rtc_time : 00:53:57 rtc_date : 2008-08-27 alrm_time : 00:00:00 alrm_date : ****-**-01 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 rtc_time : 00:54:06 rtc_date : 2008-08-27 alrm_time : 00:59:01 alrm_date : ****-08-27 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 and this with RTC wakeup disabled in BIOS: rtc_time : 00:44:22 rtc_date : 2008-08-27 alrm_time : 00:39:36 alrm_date : ****-**-** 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 rtc_time : 00:44:27 rtc_date : 2008-08-27 alrm_time : 00:49:25 alrm_date : ****-08-27 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
Thanks. Next, can you please do the same with commit e1094bfa26e5e94af2fea79e004614dbce42b008 reverted?
Hi, Stefan From the info in comment #30 it seems that the Alarm IRQ bit is always unset after the RTC alram is set regardless whether RTC wakeup is enabled in BIOS. If so, the system can't be waked by RTC wakeup on Asus A8V. Maybe the system can't be waked up from S3/S4 by RTC wakeup. But from the info in comment #26 it seems that patch in omment #19 can work on MSI K8NGM2-FID system. Will you please confirm whether the patch can work on the Gigabyte board? Please also confirm whether the system can be waked up from S3/S4 by RTC wakeup on Asus A8V system. thansk.
(In reply to comment #31) > Thanks. Next, can you please do the same with commit > e1094bfa26e5e94af2fea79e004614dbce42b008 reverted? This is e1094bfa26e5e94af2fea79e004614dbce42b008 checked out and then reverted, RTC wakeup enabled in BIOS: rtc_time : 08:36:40 rtc_date : 2008-08-27 alrm_time : 08:41:32 alrm_date : ****-08-27 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 rtc_time : 08:36:49 rtc_date : 2008-08-27 alrm_time : 08:41:43 alrm_date : ****-08-27 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 And the system wakes up. I think that alarm_IRQ is always no is another issue independent from this one (it is always no even on 2.6.25).
(In reply to comment #33) > (In reply to comment #31) > > Thanks. Next, can you please do the same with commit > > e1094bfa26e5e94af2fea79e004614dbce42b008 reverted? > > This is e1094bfa26e5e94af2fea79e004614dbce42b008 checked out and then > reverted, > RTC wakeup enabled in BIOS: > > [...] > > And the system wakes up. This is the Asus A8V, I forgot to mention. I can test the Gigabyte soonest at friday, sorry.
Well, something seriously strange is going on here. I would expect that in the working case (ie. with commit e1094bfa26e5e94af2fea79e004614dbce42b008) alarm_IRQ will be set to 'yes' after enabling the wake alarm. Can you please unset CONFIG_HPET_EMULATE_RTC and retest?
Sorry, this one is set automatically, it appears. Please try to test with CONFIG_HPET_TIMER unset.
Created attachment 17479 [details] Kernel configuration for Asus A8V Sorry, I haven't told you that I use a different config on the Asus A8V board, that's it.
(In reply to comment #36) > Please try to test with CONFIG_HPET_TIMER unset. I can't unset this, it depends on CONFIG_X86_32, on the Asus I have CONFIG_X86_64.
Hi, Stefan From the info in comment #30 and #33 it seems that the flag of Alarm IRQ is always unset on Asus 8V system regardless of the kernel version. As the flag of Alarm IRQ is unset, it indicates the AIE bit of RTC_CONTROL register is clear. In such case the RTC event won't be enabled in the function of cmos_suspend, which causes that RTC can't wake the system from S5. Will you please double check whether the system can be waked up from S3/S4 by RTC wakeup on Asus A8V board? ( Any kernel after 2.6.25-rc6 is OK) Of course it will be great if you can test it on Gigabyte board. Thanks.
(In reply to comment #39) > From the info in comment #30 and #33 it seems that the flag of Alarm IRQ > is > always unset on Asus 8V system regardless of the kernel version. Yes, that's true. > As the flag of Alarm IRQ is unset, it indicates the AIE bit of RTC_CONTROL > register is clear. In such case the RTC event won't be enabled in the > function > of cmos_suspend, which causes that RTC can't wake the system from S5. > Will you please double check whether the system can be waked up from S3/S4 > by RTC wakeup on Asus A8V board? ( Any kernel after 2.6.25-rc6 is OK) The system can not be waked up from S3, neither with 2.6.25 nor with 2.6.26-rc9. I was wondering about that, but that's the case, 2.6.25 wakes from S5 but not from S3, 2.6.26-rc9 wakes from none. > Of course it will be great if you can test it on Gigabyte board. I really like to, please be patient until weekend.
Thank you for your work and patience, I tested 2.6.27-rc4 + bug 11153 comment 18 + bug 11411 comment 19 on the Gigabyte GA-6OXM7 and it works. System wakes from S3 and S5. cat /proc/driver/rtc rtc_time : 12:02:13 rtc_date : 2008-08-30 alrm_time : 12:06:11 alrm_date : 2008-08-30 alarm_IRQ : yes alrm_pending : no 24hr : yes periodic_IRQ : no update_IRQ : no HPET_emulated : no DST_enable : no periodic_freq : 1024 batt_status : okay ...also looks clean. I'm going to do some investigations (printk) with the Asus on this on my own, maybe I could find something out. --Stefan
(In reply to comment #19) > Created an attachment (id=17455) [details] > try the debug patch based on the patch in comment #8 > > Sorry that I attached the incorrect patch.(The input parameter in shutdown > method should be "struct device" rather than PNP device.) > > Thank David Brownell for your helps. Could I please have a Cc : Stefan Bauer <stefan.bauer@cs.tu-chemnitz.de> ?
Hi, Stefan Will you please confirm whether the system can be waked up by RTC wakeup from S5 only if the patch in comment #19 is applied on the kernel of 2.6.27-rc4? As the bug can be fixed after the patches in comment #19 and bug 11153 comment 18 are applied, can the bug be marked as resoved? thanks.
(In reply to comment #43) > Hi, Stefan > Will you please confirm whether the system can be waked up by RTC wakeup > from S5 only if the patch in comment #19 is applied on the kernel of > 2.6.27-rc4? I tested rc5 + comment 19, hope that is ok, and can confirm that the Gigabyte wakes up from S5. > As the bug can be fixed after the patches in comment #19 and bug 11153 > comment 18 are applied, can the bug be marked as resoved? I'm not shure to decide this. It depends on why the Asus board still doesn't wake up from S5 with 2.6.27-rc4 + comment 19, but with 2.6.25. Probably the Asus-issue should become a separate bug, hence it even never wakes from S3? Regards, Stefan
Well, I think it's better to open a separate bug for the Asus issue, note in there that the problem is system-specific, the thing worked with 2.6.25 and what broke it.
Hi, Stefan Thanks for the confirmation. IMO the issue on Asus board is different with that on Gigabyte board. From the log in comment #33 we can know that the Alarm_IRQ bit isn't set event after setting the RTC alarm time. The Alarm_IRQ bit is used to determine whether the RTC event handler needs to be enabled in the course of suspend/shutdown. (On the Asus board the system can't be waked up from S3 by RTC wakeup.) Maybe the first issue for the Asus board is to identify why the Alarm_IRQ bit is not set after setting RTC alarm time.
The patch is now in the mainline kernel GIT tree, by the way. Agreed that the ASUS issue is different. When you post that bug report please don't forget the full boot time dmesg and "lspci -vv" output ... K8T800/VT8237 yes? Can you verify that the RTC registers can be written, e.g. to some other date? I noticed in an extract of the vt8235 data sheet that there's an RTC write protect bit. Maybe that was set by the BIOS.
ok, let's close this track. Please open another bug for ASUS board.
ACPI with Kernel 2.6.27 (Ubuntu 8.10) doesn't work with Gigabyte MA78GM-S2H
please file a new bug report with a detailed description. :)
so is there a new bug report relating to asus' s5 rtc wakup?
(In reply to comment #51) > so is there a new bug report relating to asus' s5 rtc wakup? I'm sorry to say no. I resolved to do some investigation on this issue, but unfortunately I don't rely on the Asus to wake up, so my motivation to spend time on this is actually relatively low... But let me know if you want to open up one. --Stefan