Bug 5243
Summary: | IRQ8 (rtc) screams w/o pnpacpi=off -- IO-APIC-level | ||
---|---|---|---|
Product: | ACPI | Reporter: | Krzysztof Oledzki (ole) |
Component: | BIOS | Assignee: | ykzhao (yakui.zhao) |
Status: | CLOSED DUPLICATE | ||
Severity: | high | CC: | acpi-bugzilla, lenb, shaohua.li |
Priority: | P2 | ||
Hardware: | i386 | ||
OS: | Linux | ||
Kernel Version: | 2.6.13.1 | Subsystem: | |
Regression: | --- | Bisected commit-id: | |
Attachments: |
acpidump output
workaround for the issue Working workaround for this PNP BIOS bug |
Description
Krzysztof Oledzki
2005-09-13 10:16:20 UTC
> 8: 2061632970 0 0 0 IO-APIC-level rtc
This should be IO-APIC-edge
If you boot with "acpi=off" does it work better?
Also it's worthy tring 'pnpacpi=off'. Please provide the acpidmp output too. Might the BIOS provide wrong interrupt info for RTC in ACPI tables. Attached acpidump output. Will test pnpacpi=off and acpi=off tomorrow, in service window. Thanks! Created attachment 6030 [details]
acpidump output
It's a BIOS bug to me. It claims RTC's interrupt is level/active low. This is wrong. pnpacpi=off can workaround your issue. Device (RTC) { Name (_HID, EisaId ("PNP0B00")) Method (_CRS, 0, Serialized) { \ASLT (0x77) SLTL (0x10) Name (CRSP, ResourceTemplate () { IO (Decode16, 0x0070, 0x0070, 0x01, 0x04) IRQ (Level, ActiveLow, Exclusive) {8} }) Return (CRSP) } Method (_STA, 0, Serialized) { \ASLT (0x78) SLTL (0x10) If (And (ACTV, 0x01)) { Return (0x0F) } Else { Return (0x0D) (Resending - it seems that latest bugzilla crash droped my comment) True, pnpacpi=off indeed solved this problem: 8: 1 0 0 0 IO-APIC-edge rtc Thank you. Is there any other way to force IO-APIC-edge for IRQ8 than completely disabling pnpacpi? Or maybe some check for buggy bioses is possible and automatically change IO-APIC-level to IO-APIC-edge for IRQ8? PNP device interrupt typically is edge. We could make pnpacpi ignores the BIOS setting and always use edge interrupt. But I'm not sure if the assumption is always true. I'll ping Bjorn if PNP device interrupt could be level in IA64. Created attachment 6352 [details]
workaround for the issue
The BIOS has bug. It makes rtc interrupt level trigerred. This patch
workarounds it.
I wonder if this can be tested in -mm.
It seems that this workaround solved this problem only partially. CPUs are no longer flooded by interrupts (Thanks, thanks!) but hwclock no longer works. IRQ count for CPU is increase by one but hwclock fails. Strange. # cat /proc/interrupts |grep rtc;hwclock; cat /proc/interrupts|grep rtc 8: 4 0 0 0 IO-APIC-edge rtc select() to /dev/rtc to wait for clock tick timed out 8: 5 0 0 0 IO-APIC-edge rtc # cat /proc/irq/8/smp_affinity 1 A related issue has been sighted at novell 214809 where the HPET appears in the DSDT at edge/high, but it is used in RTC compatibility mode and IOAPIC mode and there is an INT_SRC_OVR that requests level/low on IRQ8. It works with pnpacpi=off because it is left at level/low instead of believing the DSDT and setting edge/high. The IBM BIOS team asserts it is a Linux bug. But here we don't have an INT_SRC_OVR on IRQ8... In any case, the workaround in comment #8 appears to be incomplete, because it sets the trigger, but not the polarity. (In reply to comment #10) <CUT> > In any case, the workaround in comment #8 appears to > be incomplete, because it sets the trigger, but not the polarity. OK, I'll try to extend this patch to also force the polarity. It should be ACPI_ACTIVE_HIGH, right? On Wed, 26 Sep 2007, bugme-daemon@bugzilla.kernel.org wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=5243 Attached patch fixed my problem, but I would like to check it on three other problematic systems to be 100% sure. So far I have tested only one. BTW: Is it possible to test it for a while in a next -mm? Best regards, Krzysztof Ol Created attachment 12951 [details]
Working workaround for this PNP BIOS bug
(In reply to comment #13) > Created an attachment (id=12951) [details] > Working workaround for this PNP BIOS bug > Now it seems that the patch can solve the problem. Will you please send the patch to the acpi maillist? Thanks for the patch. Krzysztof, can you try the patch I attached in bug 9153? There is a similar issue in the bug, but it's about BIOS override. That patch can unified handle the override issue and BIOS bug, so I consider to merge that patch if it works. On Sun, 14 Oct 2007, bugme-daemon@bugzilla.kernel.org wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=5243 > > > shaohua.li@intel.com changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Status|CLOSED |REOPENED > Resolution|CODE_FIX | > > > > > ------- Comment #15 from shaohua.li@intel.com 2007-10-14 23:21 ------- > Krzysztof, > can you try the patch I attached in bug 9153? There is a similar issue in > the > bug, but it's about BIOS override. That patch can unified handle the override > issue and BIOS bug, so I consider to merge that patch if it works. Yes, but I will be able to test it at the end of the next week, as I currently do not have a direct access to this host and I do not want to do it remotely. Sorry. :( Best regards, Krzysztof Ol Krzysztof Oledzki, do you have any test result to share with us? On Mon, 22 Oct 2007, bugme-daemon@bugzilla.kernel.org wrote: > ------- Comment #17 from michael.fu@intel.com 2007-10-22 17:28 ------- > Krzysztof Oledzki, > > do you have any test result to share with us? Not yet. Like I said previously: end of _this_ week. :) Best regards, Krzysztof Ol Patch from bug 9153 works for me: pnp: IRQ 8 is overrided to edge, high It only requires a small fix to prevent inserting empty newline: - pnp_warn("IRQ %d is overrided to %s, %s\n", + pnp_warn("IRQ %d is overrided to %s, %s", Best regards, Krzysztof Ol Thanks, I'll update the patch as you suggested. *** This bug has been marked as a duplicate of bug 9153 *** it looks like andrew morton sent the patch in comment #13 to linus, who included it in 2.6.24-rc1. 9cd8047b463f213c294f756119ac353312e7a152 (Fix very high interrupt rate for IRQ8 (rtc) unless pnpacpi=off) *** Bug 7679 has been marked as a duplicate of this bug. *** |