Bug 1320 - S3 resume: RTC fails to wakeup system
Summary: S3 resume: RTC fails to wakeup system
Status: CLOSED CODE_FIX
Alias: None
Product: ACPI
Classification: Unclassified
Component: Power-Sleep-Wake (show other bugs)
Hardware: i386 Linux
: P2 normal
Assignee: Shaohua
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-10-03 16:33 UTC by Karol Kozimor
Modified: 2005-01-21 21:41 UTC (History)
2 users (show)

See Also:
Kernel Version: 2.6.0-test6 and others
Tree: Mainline
Regression: ---


Attachments
A proposed patch by Pat Mochel (1.92 KB, patch)
2003-10-11 13:16 UTC, Karol Kozimor
Details | Diff
patch for fixing alarm bug (6.04 KB, patch)
2003-10-16 19:57 UTC, Luming Yu
Details | Diff
/proc/interrupts and dmesg with acpi_isa_irq=9 (11.18 KB, text/plain)
2003-11-13 14:49 UTC, Karol Kozimor
Details
patch for this issue (1.80 KB, patch)
2004-11-22 01:59 UTC, Shaohua
Details | Diff
the same patch with typos fixed (1.81 KB, patch)
2004-11-22 15:13 UTC, Karol Kozimor
Details | Diff
rtc alarm using FADT (3.90 KB, patch)
2004-11-22 19:16 UTC, Shaohua
Details | Diff

Description Karol Kozimor 2003-10-03 16:33:36 UTC
Hardware Environment: ASUS L3800C laptop, i845MP chipset

Software Environment: 2.6.0-test6, but also tried 2.6.0-test5-mm4 and
2.6.0-test6-mm2

Problem Description: When trying to set /proc/acpi/alarm, "irq 9: nobody cared!"
is printed, followed by a call trace and "Disabling IRQ #9". The wake-up event
is issued, however, and the system resumes from various sleep states (S1, S3, S4
tested), but no further ACPI events are reported (except those triggered
explicitely by _WAK method). 

If uhci-hcd.ko is loaded (or quite possibly, if the specific interrupt is
shared), the system will just hang (so that only power-off override works and
the fan starts spinning fast after a while) instead of printing anything. This
is also the typical 2.4.x behaviour, regardless of the modules loaded.

Steps to reproduce:
echo "yyyy-mm-dd hh:mm:ss" > /proc/acpi/alarm

Other information:
Typical /proc/interrupt contents (from 2.4.22+ACPI 20030918, but the 2.6.0-test6
output is more or less identical):
           CPU0
  0:     160595          XT-PIC  timer
  1:       9677          XT-PIC  keyboard
  2:          0          XT-PIC  cascade
  5:      63545          XT-PIC  Ricoh Co Ltd RL5c476 II, usb-uhci, radeon@PCI:1:0:0
  8:          1          XT-PIC  rtc
  9:        113          XT-PIC  acpi, ohci1394, usb-uhci
 11:      80679          XT-PIC  Ricoh Co Ltd RL5c476 II (#2), PCTel, Intel
82801CA-ICH3
 12:      63928          XT-PIC  PS/2 Mouse
 14:      13463          XT-PIC  ide0
 15:        224          XT-PIC  ide1
NMI:          0
ERR:          0

More information (dmidecode, DSDT, etc.) can be found here:
http://bugme.osdl.org/show_bug.cgi?id=1185 (bug #1185 concerns the same laptop)
Comment 1 Karol Kozimor 2003-10-11 13:16:51 UTC
Created attachment 1029 [details]
A proposed patch by Pat Mochel

A patch proposed by Pat Mochel. Makes the "Disabling IRQ" and the call trace go
away, but doesn't really help much.
Comment 2 Karol Kozimor 2003-10-11 13:26:21 UTC
Applying the patch causes the following:
- the call trace and the "Disabling IRQ#9" message are gone
- still, no further events are generated
- writing to /proc/acpi/alarm *generally* doesn't hang the machine if uhci-hcd
is loaded, though I had it lock once (either on modprobe uhci-hcd, or on writing
when the module was loaded, can't remember)

Additionally, if /proc/acpi/alarm has been read, a write *usually* (can't
confirm it) produces:
     osl-0891 [35] os_wait_semaphore     : Failed to acquire
semaphore[cfff7f00|1|0], AE_TIME
  utmisc-0745 [34] ut_acquire_mutex      : Thread 0 could not acquire Mutex
[ACPI_MTX_Hardware] AE_TIME
     osl-0891 [35] os_wait_semaphore     : Failed to acquire
semaphore[cfff7f00|1|0], AE_TIME         utmisc-0745 [34] ut_acquire_mutex     
: Thread 0 could not acquire Mutex [ACPI_MTX_Hardware] AE_TIME
Comment 3 Luming Yu 2003-10-16 19:57:40 UTC
Created attachment 1067 [details]
patch for fixing alarm bug

Please apply this patch, it fixed same issue on my T23.
Comment 4 Luming Yu 2003-10-16 20:14:57 UTC
I didn't find the proposed patch by Pat Mochel, My patch seems to be same thing.
So yon can just ignore my patch, if you had tried Pat Mochel's patch.
Comment 5 Karol Kozimor 2003-10-17 16:57:19 UTC
The patch doesn't help either. Surely, it eliminates the output, but still further ACPI events are not reported, and furthermore, nor are timer events (i.e. the machine won't wake up more than once). Additionally, those messages appear in the various moments of the cycle (I'm testing using S1):   evevent-0286: *** Error: No installed handler for fixed event [00000004]
Comment 6 Shaohua 2003-10-19 18:21:15 UTC
This patch fix the same issue in T40
karol, did you mean you get:
evevent-0286: *** Error: No installed handler for fixed event [00000004]
even if you applied the patch?
Comment 7 Karol Kozimor 2003-10-20 02:02:02 UTC
I get this error *when* I apply the patch.

Anyway, some good news and some bad news.

Good news is my ACPI interrupts / events problems aren't probably related to /proc/acpi/alarm at all. Bad news is I seem to lose those events upon *every* resume from S1. Versions affected are (for now) test[5-7], test4 just oopses and I didn't yet manage to test others, as I discovered it only yesterday. 2.4.22 with ACPI 20030918 is fine (i.e. the events are OK after resume), and I'm quite sure at least some of the -mm versions was also fine w.r. to that. I'll try nail it down to a specific kernel version.
Comment 8 Karol Kozimor 2003-10-20 07:06:22 UTC
Okay, I've nailed the problem down a little bit. The last kernel version with ACPI interrupts working after S1 resume is 2.6.0-test3. Test4 just oopses, and with test[5-8], no ACPI interrupts are produced after resume. I'll wait until those problems are fixed wth further testing.
Comment 9 Karol Kozimor 2003-10-21 15:47:26 UTC
A quick followup.

Pat: your patch seems fine, except for the mutex thing I reported earlier. A
semi-reliable way to produce this output is to write /proc/acpi/alarm, and then
immediately (with ~ .5 sec tolerance) read it.

Yu: your patch, for reasons unknown, fails to wake my system up from S4 (i.e.
pmdisk). It wakes it up from S1 once (as there are no further ACPI interrupts
generated due to another bug). Also, writing /proc/acpi/alarm produces the "No
installed handler" message.

In general: I've isolated the interrupts problems -- they're by no means caused
by /proc/acpi/alarm.
Comment 10 Len Brown 2003-11-12 23:33:23 UTC
Hmmm, this BIOS has LNKC and LNKD active on 9, 
but doesn't list 9 as a possible IRQ... 
 
> ACPI: PCI Interrupt Link [LNKC] (IRQs 3 11, enabled at IRQ 9) 
> ACPI: PCI Interrupt Link [LNKD] (IRQs 5 7 11, enabled at IRQ 9) 
 
Lets see if things get better if we kick the PCI devices off of IRQ9... 
 
Karol, 
Please try the patch in bug #430 and boot with acpi_isa_irq=9 
and attach the dmesg and /proc/interrupts 
 
thanks, 
-Len 
 
Comment 11 Karol Kozimor 2003-11-13 14:49:42 UTC
Created attachment 1438 [details]
/proc/interrupts and dmesg with acpi_isa_irq=9

I'm afraid I don't follow. Anyway, the patch doesn't really seem to change
anything.

With acpi_irq_isa=9 the kernel behaves somewhat 20030916-ish and IRQ#9 is not
shared. Thus, it is disabled once anything is written to /proc/acpi/alarm.

Without apci_irq_isa, the IRQ is shared and the system hangs as usual (note:
withouth Pat's patch applied).

Also, acpi_pci_irq doesn't seem to have any effect, but that may be a different
problem (according to the DSDT, the link devices don't seem to be very
flexible).
Comment 12 Luming Yu 2004-01-11 21:26:46 UTC
Please test patch filed at bug 1661 for losting events upon *every* resume 
from S1.
Comment 13 Karol Kozimor 2004-05-18 00:36:24 UTC
I tested 2.6.6-mm1, which is supposed to have this patch merged. In short:
2.6.6-mm1 vanilla: no wake-up, no SCI interrupts after resume,
2.6.6-mm1 with the patch from bug 2321: no wake-up, SCI interrupts fine.
Also, both kernels spit out the following upon write to /proc/acpi/alarm:

kernel:  evevent-0286: *** Error: No installed handler for fixed event [00000004]
Comment 14 Karol Kozimor 2004-07-01 14:28:32 UTC
Update: 2.6.7-mm3 will wake up once after the alarm has been successfully set,
all subsequent writes to /proc/acpi/alarm yield
 evevent-0286: *** Error: No installed handler for fixed event [00000004]
and obviously do not make the machine wake up. The SCI interrupts are fine even
after multiple suspends.
Comment 15 Len Brown 2004-11-15 21:31:19 UTC
how does this one look in 2.6.9? 
Comment 16 Karol Kozimor 2004-11-16 02:21:40 UTC
SCI interrupts are fine, but the original report was about the RTC alarm, 
which still doesn't work as expected (see previous comment, nothing has really 
changed so far). 
Comment 17 Shaohua 2004-11-16 16:59:11 UTC
Len applied the ACPICA part of the patch, but not the RTC handler part.
I tested the RTC handler part. I did receive alarm event, but my laptop can't 
wake up.
Comment 18 Shaohua 2004-11-18 21:48:00 UTC
Strange, pat's patch works for me now. But i got interrupt flood the second 
time. Will update more.
Comment 19 Shaohua 2004-11-22 01:59:53 UTC
Created attachment 4114 [details]
patch for this issue

This patch is based on Pat's patch. It now works for me like a charm. Karol,
please try it.
You will also need this patch:
http://marc.theaimsgroup.com/?l=linux-kernel&m=110111546712725&w=2
Comment 20 Karol Kozimor 2004-11-22 15:13:41 UTC
Created attachment 4121 [details]
the same patch with typos fixed

True, no matter how hard I tried (S1, S3, S4 in various combinations) I
couldn't break it. Thanks for the fix.

The attached patch has some typos fixed in the comments.

BTW: what's the purpose of the ifdef'd code in drivers/acpi/sleep/proc.c
(acpi_system_alarm_seq_show() and acpi_system_write_alarm())?
It seems indeed broken (at least the first function reads "0004-11-**
23:50:00", I don't know about writes), though my system should support DAY_ALRM
(FADT reports 0x0d).
Comment 21 Shaohua 2004-11-22 19:16:18 UTC
Created attachment 4122 [details]
rtc alarm using FADT

Thanks, Karol. I'm not a native english speaker :).
I also don't know why proc.c doesn't use FADT (in #ifdef). After some debugs,
this patch using FADT works for me.
Comment 22 Karol Kozimor 2004-11-23 13:32:15 UTC
It also seems to work correctly here, at least for setting the day value and 
reading it back. 
Comment 23 Shaohua 2004-11-23 16:40:39 UTC
The same here. Only fadt.day isn't NULL. I guess most systems don't implement 
month and year alarm.
Comment 24 Len Brown 2004-12-05 19:58:08 UTC
patch in comment #21 applied to acpi-test tree 
Comment 25 Len Brown 2005-01-21 21:41:50 UTC
shipped in 2.6.11-rc1 -- closing. 

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