Bug 1320
| Summary: | S3 resume: RTC fails to wakeup system | ||
|---|---|---|---|
| Product: | ACPI | Reporter: | Karol Kozimor (sziwan) |
| Component: | Power-Sleep-Wake | Assignee: | Shaohua (shaohua.li) |
| Status: | CLOSED CODE_FIX | ||
| Severity: | normal | CC: | acpi-bugzilla, mochel |
| Priority: | P2 | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.0-test6 and others | Subsystem: | |
| Regression: | --- | Bisected commit-id: | |
| Attachments: |
A proposed patch by Pat Mochel
patch for fixing alarm bug /proc/interrupts and dmesg with acpi_isa_irq=9 patch for this issue the same patch with typos fixed rtc alarm using FADT |
||
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.
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
Created attachment 1067 [details]
patch for fixing alarm bug
Please apply this patch, it fixed same issue on my T23.
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. 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] 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? 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. 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. 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. 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 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).
Please test patch filed at bug 1661 for losting events upon *every* resume from S1. 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] 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. how does this one look in 2.6.9? 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). 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. Strange, pat's patch works for me now. But i got interrupt flood the second time. Will update more. 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 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).
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.
It also seems to work correctly here, at least for setting the day value and reading it back. The same here. Only fadt.day isn't NULL. I guess most systems don't implement month and year alarm. patch in comment #21 applied to acpi-test tree shipped in 2.6.11-rc1 -- closing. |
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)