Most recent kernel where this bug did not occur:2.6.20 Distribution: FC6 Hardware Environment: ASUS A8N-SLI mobo, Athlon 64 3200+, PATA Disk Software Environment: FC6, MythTV 0.20.2-164 Problem Description: Change in kernel code from support for /proc/acpi/alarm to /sys/class/rtc/rtc0/wakealarm and supporting code borked working system. Will no longer wake at set time. Time set <> time reported by cat /sys.../wakealarm. Return value off by large constant. Note: Mobo doesn't support month, day, or year in alarm setting. Steps to reproduce: Before upgrade from 2.6.20 to 2.6.22.2, suspend-to-disk with powerdown to standby would wake at time echoed into /proc/acpi/alarm. Change of wakeup time setting code to echo 0 to /sys/class/rtc/rtc0/wakealarm followed by echo of seconds since epoch of desired wakeup time under 2.6.22.2 does not work. System will not wake up at specified time. Will wake by keyboard keystroke, such as Ctrl+Esc. Tried enabling APM (BIOS) alarm setting and all entries under /proc/acpi/wakeup (all on at once), but no improvement. Test sequence: # echo 0 > /sys/class/rtc/rtc0/wakealarm # t=`date +%s`; w=`expr $t + 60`; echo $w > /sys/class/rtc/rtc0/wakealarm # echo $w 1189268800 # cat /sys/class/rtc/rtc0/wakealarm 2076101696 # expr 2076101696 - 1189268800 886832896 <invoke your favorite code to suspend to disk and power down system leaving standby power on> <wait> <wait some more> <hit power on button>
Reply-To: akpm@linux-foundation.org On Sat, 8 Sep 2007 09:29:18 -0700 (PDT) bugme-daemon@bugzilla.kernel.org wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=8995 > > Summary: /proc/acpi/alarm worked; update to 2.6.22.2 and > /sys/class/rtc/rtc0/wakealarm don't > Product: ACPI > Version: 2.5 > KernelVersion: 2.6.22.2 > Platform: All > OS/Version: Linux > Tree: Mainline > Status: NEW > Severity: normal > Priority: P1 > Component: Power-Sleep-Wake > AssignedTo: acpi_power-sleep-wake@kernel-bugs.osdl.org > ReportedBy: huffcslists@gmail.com > > > Most recent kernel where this bug did not occur:2.6.20 > Distribution: FC6 > Hardware Environment: ASUS A8N-SLI mobo, Athlon 64 3200+, PATA Disk > Software Environment: FC6, MythTV 0.20.2-164 > Problem Description: > Change in kernel code from support for /proc/acpi/alarm to > /sys/class/rtc/rtc0/wakealarm and supporting code borked working system. > Will > no longer wake at set time. > Time set <> time reported by cat /sys.../wakealarm. Return value off by > large > constant. Note: Mobo doesn't support month, day, or year in alarm setting. > > Steps to reproduce: > Before upgrade from 2.6.20 to 2.6.22.2, suspend-to-disk with powerdown to > standby would wake at time echoed into /proc/acpi/alarm. Change of wakeup > time > setting code to echo 0 to /sys/class/rtc/rtc0/wakealarm followed by echo of > seconds since epoch of desired wakeup time under 2.6.22.2 does not work. > System will not wake up at specified time. Will wake by keyboard keystroke, > such as Ctrl+Esc. Tried enabling APM (BIOS) alarm setting and all entries > under /proc/acpi/wakeup (all on at once), but no improvement. > Test sequence: > # echo 0 > /sys/class/rtc/rtc0/wakealarm > # t=`date +%s`; w=`expr $t + 60`; echo $w > /sys/class/rtc/rtc0/wakealarm > # echo $w > 1189268800 > # cat /sys/class/rtc/rtc0/wakealarm > 2076101696 > # expr 2076101696 - 1189268800 > 886832896 > <invoke your favorite code to suspend to disk and power down system leaving > standby power on> > <wait> > <wait some more> > <hit power on button> > Guys, can we please work out where the problem lies here? Is it in the new RTC code, ACPI or what? Thanks.
On Sunday, 9 September 2007 02:29, Andrew Morton wrote: > On Sat, 8 Sep 2007 09:29:18 -0700 (PDT) bugme-daemon@bugzilla.kernel.org > wrote: > > > http://bugzilla.kernel.org/show_bug.cgi?id=8995 > > > > Summary: /proc/acpi/alarm worked; update to 2.6.22.2 and > > /sys/class/rtc/rtc0/wakealarm don't > > Product: ACPI > > Version: 2.5 > > KernelVersion: 2.6.22.2 > > Platform: All > > OS/Version: Linux > > Tree: Mainline > > Status: NEW > > Severity: normal > > Priority: P1 > > Component: Power-Sleep-Wake > > AssignedTo: acpi_power-sleep-wake@kernel-bugs.osdl.org > > ReportedBy: huffcslists@gmail.com > > > > > > Most recent kernel where this bug did not occur:2.6.20 > > Distribution: FC6 > > Hardware Environment: ASUS A8N-SLI mobo, Athlon 64 3200+, PATA Disk > > Software Environment: FC6, MythTV 0.20.2-164 > > Problem Description: > > Change in kernel code from support for /proc/acpi/alarm to > > /sys/class/rtc/rtc0/wakealarm and supporting code borked working system. > Will > > no longer wake at set time. > > Time set <> time reported by cat /sys.../wakealarm. Return value off by > large > > constant. Note: Mobo doesn't support month, day, or year in alarm setting. > > > > Steps to reproduce: > > Before upgrade from 2.6.20 to 2.6.22.2, suspend-to-disk with powerdown to > > standby would wake at time echoed into /proc/acpi/alarm. Change of wakeup > time > > setting code to echo 0 to /sys/class/rtc/rtc0/wakealarm followed by echo of > > seconds since epoch of desired wakeup time under 2.6.22.2 does not work. > > System will not wake up at specified time. Will wake by keyboard > keystroke, > > such as Ctrl+Esc. Tried enabling APM (BIOS) alarm setting and all entries > > under /proc/acpi/wakeup (all on at once), but no improvement. > > Test sequence: > > # echo 0 > /sys/class/rtc/rtc0/wakealarm > > # t=`date +%s`; w=`expr $t + 60`; echo $w > /sys/class/rtc/rtc0/wakealarm > > # echo $w > > 1189268800 > > # cat /sys/class/rtc/rtc0/wakealarm > > 2076101696 > > # expr 2076101696 - 1189268800 > > 886832896 > > <invoke your favorite code to suspend to disk and power down system leaving > > standby power on> > > <wait> > > <wait some more> > > <hit power on button> > > > > Guys, can we please work out where the problem lies here? Is it in the > new RTC code, ACPI or what? 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
(In reply to comment #2) > > 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. > Update: Craig, can you test the 2.6.23-rc7 kernel with the patches from: http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.23-rc7/patches/ applied, please?
On 9/23/07, bugme-daemon@bugzilla.kernel.org < bugme-daemon@bugzilla.kernel.org> wrote: > > > Update: > > Craig, can you test the 2.6.23-rc7 kernel with the patches from: > > http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.23-rc7/patches/ > > applied, please? Would love to, but... You're talking to an rpm weenie. I have years of experience in software development and Solaris administration, but I haven't had any reason before to do anything with Linux that involved anything more than "yum -y update xxxx". I'm willing to give it a go if you are willing to take the time to tell me the steps I need to take to get the patches and install them (and what to do to back them out if they make things worse). Craig. On 9/23/07, <b class="gmail_sendername"><a href="mailto:bugme-daemon@bugzilla.kernel.org">bugme-daemon@bugzilla.kernel.org</a></b> <<a href="mailto:bugme-daemon@bugzilla.kernel.org">bugme-daemon@bugzilla.kernel.org</a>> wrote: <div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>Update:<br><br>Craig, can you test the 2.6.23-rc7 kernel with the patches from: <br><br><a href="http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.23-rc7/patches/">http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.23-rc7/patches/</a><br><br>applied, please?</blockquote><div><br>Would love to, but... You're talking to an rpm weenie. I have years of experience in software development and Solaris administration, but I haven't had any reason before to do anything with Linux that involved anything more than "yum -y update xxxx". <br><br>I'm willing to give it a go if you are willing to take the time to tell me the steps I need to take to get the patches and install them (and what to do to back them out if they make things worse).<br></div><br> Craig.<br><br></div>
On Sunday, 23 September 2007 15:14, you wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=8995 > > > > > > ------- Comment #4 from huffcslists@gmail.com 2007-09-23 06:14 ------- > > Would love to, but... You're talking to an rpm weenie. I have years of > experience in software development and Solaris administration, but I haven't > had any reason before to do anything with Linux that involved anything more > than "yum -y update xxxx". > > I'm willing to give it a go if you are willing to take the time to tell me > the steps I need to take to get the patches and install them (and what to do > to back them out if they make things worse). Sure. What bootloader do you use, GRUB or LILO?
To add another data point, I see the same problem on my laptop, an ASUS A6U series laptop running FC6. ACPI resume worked on kernel 2.6.20 and stopped working after the upgrade 2.6.22 (both official Fedora rpms)
(In reply to comment #6) > To add another data point, I see the same problem on my laptop, an ASUS A6U > series laptop running FC6. ACPI resume worked on kernel 2.6.20 and stopped > working after the upgrade 2.6.22 (both official Fedora rpms) Can you test the 2.6.23-rc8 kernel with the patches from: http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.23-rc8/patches/ applied?
I can try, but these patches don't apply cleanly. 36-acpi-video-mode-fix.patch 38-ACPI-suspend-consolidate-handling-of-Sx-states.patch 39-consolidate_Sx_handling_addendum.patch 40-ACPI-disable-lower-idle-C-states-across-suspend_resume.patch 41-clockevents-remove-the-suspend_resume-workaround_thinko.patch all give "Reversed (or previously applied) patch detected!" (so I elected to skip them) while 42-move_acpi_sleep_prepare_outside_of_CONFIG_SUSPEND.patch gives Hunk #1 succeeded at 48 with fuzz 2 (offset 22 lines). Hunk #2 FAILED at 102. I don't usually build my own kernels, so maybe this is user error, but is it worth building with the source in this state or should I try something else?
Sorry, my bad. There were too many patches on the server, some of them being outdated. I removed the wrong ones, but since you have downloaded all of them already, please apply only the patches listed in the series file.
The short answer is: yes acpi wakeup works. I used rtcwake, and provided I switched off autofs first, I could suspend to disk and it would wake as scheduled. If I tried suspend to mem, then at the scheduled time the fan would start but nothing else would come on and I had to do a forced reboot. For kernel 2.6.20 I was using swsusp2 which I think does a suspend to disk, so with theses patches I think I have the functionality I had before. If you need more info, let me know.
Yes, I'd like to identify the exact patch that helps. Can you please revert 38-hibernation-enter-platform-hibernation-state-in-a-consistent-way-rev-4-fix.patch 37-hibernation-enter-platform-hibernation-state-in-a-consistent-way-rev-4.patch in this order, and see if the problem reapears?
With those patches removed, acpi wakeup does not work on my laptop.
OK, thanks for testing. I hope that these two patches will be in 2.6.24.
(In reply to comment #13) > OK, thanks for testing. > > I hope that these two patches will be in 2.6.24. > Patches are being removed in latest -mm (as accepted for 2.6.24), but not yet appeared on linus' git HEAD. Question: i'm on X86_64 with a kernel 2.6.22 and i still have the old /proc/acpi/alarm interface and not the newer one on /sys. The new interface should be supported on X86_64? If so, could be a misconfiguration or a bug in Kbuild? Tnx
Reply-To: david-b@pacbell.net Re http://bugzilla.kernel.org/show_bug.cgi?id=8995 ... On Sunday 09 September 2007, Rafael J. Wysocki wrote: > I think the suspend/hibernation code ordering changes after > 2.6.20 are to blame here. So what's the status of this now ... are we back to having the /sys/class/rtc/rtc0/wakealarm work with ACPI again, with /sys/power/state written as "standby", "mem", or "disk" (At least on the systems where it used to work. I've had bad luck with ACPI wake on most systems. So while it'd be great to see it working everywhere, I'm just asking about the regression here.) - Dave p.s. some folk may need the appended patch. ===== CUT HERE From: Mark Lord <lkml@rtr.ca> This patch fixes rtc-cmos to ignore the two upper bits when reading the BCD mday (day of month) register from CMOS. Some systems (eg. mine) seem to have the top bit set to "1" for some reason. Signed-off-by: Mark Lord <mlord@pobox.com> Acked-by: David Brownell <dbrownell@users.sourceforge.net> Cc: Alessandro Zummo <a.zummo@towertech.it> --- a/drivers/rtc/rtc-cmos.c 2007-11-03 16:24:09.000000000 -0400 +++ b/drivers/rtc/rtc-cmos.c 2007-11-03 16:26:51.000000000 -0400 @@ -120,7 +120,8 @@ t->time.tm_hour = CMOS_READ(RTC_HOURS_ALARM); if (cmos->day_alrm) { - t->time.tm_mday = CMOS_READ(cmos->day_alrm); + /* ignore upper bits on readback per ACPI spec */ + t->time.tm_mday = CMOS_READ(cmos->day_alrm) & 0x3f; if (!t->time.tm_mday) t->time.tm_mday = -1;
On Sunday, 4 of November 2007, David Brownell wrote: > Re http://bugzilla.kernel.org/show_bug.cgi?id=8995 ... > > On Sunday 09 September 2007, Rafael J. Wysocki wrote: > > I think the suspend/hibernation code ordering changes after > > 2.6.20 are to blame here. > > So what's the status of this now ... are we back to having > the /sys/class/rtc/rtc0/wakealarm work with ACPI again, with > /sys/power/state written as "standby", "mem", or "disk" Yes, it should work now. The fix for the "disk" case is in the mainline: 9cd9a0058dd35268b24fa16795a92c800f4086d4 Author: Rafael J. Wysocki <rjw@sisk.pl> Date: Thu Oct 18 03:04:56 2007 -0700 Hibernation: Enter platform hibernation state in a consistent way.
Reply-To: david-b@pacbell.net On Sunday 04 November 2007, Rafael J. Wysocki wrote: > On Sunday, 4 of November 2007, David Brownell wrote: > > > > So what's the status of this now ... are we back to having > > the /sys/class/rtc/rtc0/wakealarm work with ACPI again > > Yes, it should work now. A current git kernel seemed to work for me on at least one system that had previously misbehaved ... both "standby" and "disk" suspend now let the wakealarm do its thing. (And STR has the usual unrelated framebuffer issues.) And I'm told another person has seen it work again on his hardware. I'll try it on a few other systems too, just to be sure. Thanks for the bugfix, and update! - Dave
On Monday, 5 of November 2007, bugme-daemon@bugzilla.kernel.org wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=8995 > > > > > > ------- Comment #17 from anonymous@kernel-bugs.osdl.org 2007-11-05 08:11 > ------- > Reply-To: david-b@pacbell.net > > On Sunday 04 November 2007, Rafael J. Wysocki wrote: > > On Sunday, 4 of November 2007, David Brownell wrote: > > > > > > So what's the status of this now ... are we back to having > > > the /sys/class/rtc/rtc0/wakealarm work with ACPI again > > > > Yes, it should work now. > > A current git kernel seemed to work for me on at least one > system that had previously misbehaved ... both "standby" and > "disk" suspend now let the wakealarm do its thing. (And STR > has the usual unrelated framebuffer issues.) And I'm told > another person has seen it work again on his hardware. I'll > try it on a few other systems too, just to be sure. > > Thanks for the bugfix, and update! Unfortunately, the fix has exposed the issue showing up as Bug #9258 . I have a temporary workaround that I'm going to attach to Bug #8995 in a while.
Created attachment 13930 [details] Patch to work around the EHCI issue caused by the fix Dave, will this patch break /sys/class/rtc/rtc0/wakealarm vs hibernation again?
I've lost track of what's going on here, but I suspect it would break rtc wakeups. Re the EHCI thing, Alan recently posted a patch which adds a one microframe (125 usec) delay between suspending the last port and putting the EHCI controller into suspend state, and that could conceivably be a real fix for that EHCI issue. It's about the right level of hardware oddity. The delay goes before the ehci_halt() in ehci-hub::ehci_bus_suspend() ... to be fully paranoid, make it a full frame (millisecond) if you want to experiment.
Fixed in the mainline by commit 9cd9a0058dd35268b24fa16795a92c800f4086d4.