Bug 11411 - Regression 2.6.26-rc5 .. 2.6.26-rc6: RTC wakeup from S5 doesn't work anymore
Summary: Regression 2.6.26-rc5 .. 2.6.26-rc6: RTC wakeup from S5 doesn't work anymore
Status: CLOSED PATCH_ALREADY_AVAILABLE
Alias: None
Product: ACPI
Classification: Unclassified
Component: Power-Off (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: Stefan Bauer
URL:
Keywords:
Depends on:
Blocks: 10492
  Show dependency tree
 
Reported: 2008-08-23 05:03 UTC by Stefan Bauer
Modified: 2008-11-11 14:37 UTC (History)
8 users (show)

See Also:
Kernel Version: 2.6.26-rc6
Tree: Mainline
Regression: Yes


Attachments
Kernel configuration (25.05 KB, text/plain)
2008-08-23 05:08 UTC, Stefan Bauer
Details
acpidump output (51.07 KB, text/plain)
2008-08-23 08:42 UTC, Stefan Bauer
Details
Patch against "ACPI: Disable Fixed_RTC event when installing RTC handler" (1.73 KB, patch)
2008-08-23 09:11 UTC, Stefan Bauer
Details | Diff
Patch to test (1.58 KB, patch)
2008-08-24 05:39 UTC, Rafael J. Wysocki
Details | Diff
try the debug patch based on the patch in comment #8 (2.49 KB, patch)
2008-08-25 20:01 UTC, ykzhao
Details | Diff
try the debug patch based on the patch in comment #8 (2.48 KB, patch)
2008-08-26 01:32 UTC, ykzhao
Details | Diff
Kernel configuration for Asus A8V (41.76 KB, text/plain)
2008-08-27 06:49 UTC, Stefan Bauer
Details

Description Stefan Bauer 2008-08-23 05:03:08 UTC
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
Comment 1 Stefan Bauer 2008-08-23 05:08:28 UTC
Created attachment 17382 [details]
Kernel configuration
Comment 2 Stefan Bauer 2008-08-23 06:57:18 UTC
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
Comment 3 ykzhao 2008-08-23 07:31:18 UTC
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.     
    
Comment 4 Stefan Bauer 2008-08-23 08:40:45 UTC
(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.
Comment 5 Stefan Bauer 2008-08-23 08:42:40 UTC
Created attachment 17398 [details]
acpidump output
Comment 6 Stefan Bauer 2008-08-23 09:11:28 UTC
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
Comment 7 Hartmut Birr 2008-08-23 14:52:54 UTC
For clarification, only the changes in cmos_set_alarm() have an effect. The shutdown function is never called on a shutdown.

-Hartmut (e9hack)
Comment 8 Rafael J. Wysocki 2008-08-24 05:39:28 UTC
Created attachment 17412 [details]
Patch to test

Incidentally, I've been looking into this recently.

Stefan, can you try this patch, please?
Comment 9 Stefan Bauer 2008-08-24 07:40:22 UTC
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.
Comment 10 Hartmut Birr 2008-08-24 09:02:28 UTC
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().
Comment 11 Zhang Rui 2008-08-24 20:05:10 UTC
(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. :)
Comment 12 Stefan Bauer 2008-08-25 00:29:48 UTC
(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.
Comment 13 Rafael J. Wysocki 2008-08-25 15:28:37 UTC
(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.
Comment 14 Rafael J. Wysocki 2008-08-25 15:33:05 UTC
Hmm.  Stefan, please set CONFIG_HIBERNATION or CONFIG_SUSPEND and retest with the patch from Comment #8, thanks.
Comment 15 Rafael J. Wysocki 2008-08-25 15:51:36 UTC
Scratch that, sorry, you have CONFIG_PM=y and that should be sufficient.  I'll _really_ have to do some debugging.
Comment 16 ykzhao 2008-08-25 18:54:09 UTC
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.
Comment 17 ykzhao 2008-08-25 20:01:13 UTC
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.
Comment 18 David Brownell 2008-08-26 00:42:39 UTC
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.
Comment 19 ykzhao 2008-08-26 01:32:29 UTC
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.
Comment 20 Stefan Bauer 2008-08-26 01:57:21 UTC
(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.
Comment 21 Rafael J. Wysocki 2008-08-26 02:51:59 UTC
Did you apply the patch from Bug #11153 comment 18 as suggested by David?
Comment 22 Stefan Bauer 2008-08-26 11:05:25 UTC
(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.
Comment 23 Rafael J. Wysocki 2008-08-26 11:54:13 UTC
Is there anything in /sys/class/rtc/rtc0/power/wakeup on your system?
Comment 24 Rafael J. Wysocki 2008-08-26 12:22:16 UTC
Sorry, in /sys/devices/pnp0/00:02/power/wakeup ?
Comment 25 Stefan Bauer 2008-08-26 12:50:09 UTC
(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?
Comment 26 Hartmut Birr 2008-08-26 13:23:01 UTC
(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
Comment 27 Rafael J. Wysocki 2008-08-26 13:30:35 UTC
Stefan, no, that's fine.

What's in /proc/driver/rtc ?
Comment 28 Rafael J. Wysocki 2008-08-26 15:14:13 UTC
OK, the patch from Comment #19 works on my test box too.
Comment 29 Rafael J. Wysocki 2008-08-26 15:16:06 UTC
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?
Comment 30 Stefan Bauer 2008-08-26 16:08:26 UTC
(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
Comment 31 Rafael J. Wysocki 2008-08-26 16:26:55 UTC
Thanks.  Next, can you please do the same with commit e1094bfa26e5e94af2fea79e004614dbce42b008 reverted?
Comment 32 ykzhao 2008-08-26 19:13:41 UTC
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.
Comment 33 Stefan Bauer 2008-08-26 23:49:17 UTC
(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).
Comment 34 Stefan Bauer 2008-08-26 23:54:58 UTC
(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.
Comment 35 Rafael J. Wysocki 2008-08-27 03:35:47 UTC
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?
Comment 36 Rafael J. Wysocki 2008-08-27 03:41:59 UTC
Sorry, this one is set automatically, it appears.  Please try to test with CONFIG_HPET_TIMER unset.
Comment 37 Stefan Bauer 2008-08-27 06:49:31 UTC
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.
Comment 38 Stefan Bauer 2008-08-27 06:59:26 UTC
(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.
Comment 39 ykzhao 2008-08-27 20:04:02 UTC
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.
   
Comment 40 Stefan Bauer 2008-08-28 01:58:53 UTC
(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.
Comment 41 Stefan Bauer 2008-08-30 05:10:56 UTC
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
Comment 42 Stefan Bauer 2008-08-30 05:21:50 UTC
(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>

?
Comment 43 ykzhao 2008-08-31 19:15:32 UTC
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.
Comment 44 Stefan Bauer 2008-09-05 23:23:35 UTC
(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
Comment 45 Rafael J. Wysocki 2008-09-06 03:29:27 UTC
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.
Comment 46 ykzhao 2008-09-08 00:46:38 UTC
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.
    
Comment 47 David Brownell 2008-09-08 01:14:54 UTC
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. 
Comment 48 Shaohua 2008-09-09 23:30:00 UTC
ok, let's close this track. Please open another bug for ASUS board.
Comment 49 Klemm 2008-11-06 11:07:58 UTC
ACPI with Kernel 2.6.27 (Ubuntu 8.10) doesn't work with Gigabyte MA78GM-S2H
Comment 50 Zhang Rui 2008-11-06 17:26:58 UTC
please file a new bug report with a detailed description. :)
Comment 51 Patrick 2008-11-11 13:13:56 UTC
so is there a new bug report relating to asus' s5 rtc wakup?
Comment 52 Stefan Bauer 2008-11-11 14:37:50 UTC
(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

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