Marcel Holtmann reports: ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 22 low level) ... ACPI: Subsystem revision 20040311 ACPI: SCI (IRQ22) allocation failed ACPI-0133: *** Error: Unable to install System Control Interrupt Handler, AE_NOT_ACQUIRED ACPI: Unable to start the ACPI Interpreter ... ACPI: ACPI tables contain no PCI IRQ routing entries PCI: Invalid ACPI-PCI IRQ routing table PCI: Probing PCI hardware PCI: Probing PCI hardware (bus 00) PCI: Enabled i801 SMBus device Transparent bridge - 0000:00:1e.0 PCI: Using IRQ router PIIX/ICH [8086/2440] at 0000:00:1f.0 PCI BIOS passed nonexistent PCI bus 0! PCI BIOS passed nonexistent PCI bus 0! There are two bugs here. 1. non graceful failure upon AE_NOT_ACQUIRED 2. AE_NOT_ACQUIRED on non-identity mapped SCI over-ride.
Created attachment 2395 [details] patch for SCI over-ride for non-identity mapped SCI over-ride , please try the patch
Created attachment 2396 [details] patch for AE_NOT_ACQUIRED error for AE_NOT_ACQUIRED error, please try the proposal patch.
from Marcel: I applied your two patches from the bug report (btw one of them has a wrong directory in the diff) and the systems boots up in a better state, which means that a least my USB subsystem is now working. But the network is still broken and I disabled the SCSI and the IEEE1394 drivers for now. However I see these two oops along ohci_hcd: 2004 Feb 02 USB 1.1 'Open' Host Controller (OHCI) Driver (PCI) ohci_hcd: block sizes: ed 64 td 64 ohci_hcd 0000:02:0c.0: OHCI Host Controller ohci_hcd 0000:02:0c.0: irq 20, pci mem e12a5000 ohci_hcd 0000:02:0c.0: new USB bus registered, assigned bus number 3 hub 3-0:1.0: USB hub found hub 3-0:1.0: 3 ports detected ohci_hcd 0000:02:0c.1: OHCI Host Controller ohci_hcd 0000:02:0c.1: irq 21, pci mem e12b4000 ohci_hcd 0000:02:0c.1: new USB bus registered, assigned bus number 4 hub 4-0:1.0: USB hub found hub 4-0:1.0: 2 ports detected irq 21: nobody cared! Call Trace: [<c0108e32>] __report_bad_irq+0x2a/0x8b [<c0108f1c>] note_interrupt+0x6f/0x9f [<c01091de>] do_IRQ+0x127/0x136 [<c01076ac>] common_interrupt+0x18/0x20 handlers: [<e12858a3>] (usb_hcd_irq+0x0/0x67 [usbcore]) Disabling IRQ #21 usb 3-2: new full speed USB device using address 2 and Linux Kernel Card Services options: [pci] [cardbus] [pm] PCI: Enabling device 0000:02:0e.0 (0000 -> 0002) Yenta: CardBus bridge found at 0000:02:0e.0 [133f:3000] Yenta: Enabling burst memory read transactions Yenta: Using CSCINT to route CSC interrupts to PCI Yenta: Routing CardBus interrupts to PCI Yenta: ISA IRQ mask 0x0000, PCI irq 18 Socket status: 10000047 irq 22: nobody cared! Call Trace: [<c0108e32>] __report_bad_irq+0x2a/0x8b [<c0108f1c>] note_interrupt+0x6f/0x9f [<c01091de>] do_IRQ+0x127/0x136 [<c01076ac>] common_interrupt+0x18/0x20 [<c011007b>] mtrr_ioctl+0x253/0x6a7 [<c0104b91>] default_idle+0x23/0x26 [<c0104bef>] cpu_idle+0x2c/0x35 [<c02f46f2>] start_kernel+0x16b/0x188 [<c02f444b>] unknown_bootoption+0x0/0x110 handlers: [<c01b8c63>] (acpi_irq+0x0/0x16) Disabling IRQ #22 Actually I am not able to get the full dmesg so here are the initial parts that are ACPI related ENABLING IO-APIC IRQs init IO_APIC IRQs IO-APIC (apicid-pin) 2-0, 2-9, 2-16, 2-17, 2-18, 2-19, 2-20, 2-21, 2-23 not connected. ..TIMER: vector=0x31 pin1=2 pin2=-1 ..MP-BIOS bug: 8254 timer not connected to IO-APIC ...trying to set up timer (IRQ0) through the 8259A ... failed. ...trying to set up timer as Virtual Wire IRQ... works. Using local APIC timer interrupts. calibrating APIC timer ... ..... CPU clock speed is 2017.0707 MHz. ..... host bus clock speed is 100.0885 MHz. NET: Registered protocol family 16 PCI: PCI BIOS revision 2.10 entry at 0xf11f0, last bus=3 PCI: Using configuration type 1 mtrr: v2.0 (20020519) ACPI: Subsystem revision 20040311 ACPI: Interpreter enabled ACPI: Using IOAPIC for interrupt routing ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11 12 14 15) ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 *10 11 12 14 15) ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 *7 9 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 *5 6 7 9 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 *6 7 9 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 *9 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 *9 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 *9 10 11 12 14 15) ACPI: PCI Root Bridge [PCI0] (00:00) PCI: Probing PCI hardware (bus 00) PCI: Enabled i801 SMBus device Transparent bridge - 0000:00:1e.0 ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCI1._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCI2._PRT] IOAPIC[0]: Set PCI routing entry (2-17 -> 0xa9 -> IRQ 17 Mode:1 Active:1) 00:00:1f[B] -> 2-17 -> IRQ 17 IOAPIC[0]: Set PCI routing entry (2-23 -> 0xb1 -> IRQ 23 Mode:1 Active:1) 00:00:1f[C] -> 2-23 -> IRQ 23 IOAPIC[0]: Set PCI routing entry (2-19 -> 0xb9 -> IRQ 19 Mode:1 Active:1) 00:00:1f[D] -> 2-19 -> IRQ 19 IOAPIC[0]: Set PCI routing entry (2-16 -> 0xc1 -> IRQ 16 Mode:1 Active:1) 00:01:00[A] -> 2-16 -> IRQ 16 IOAPIC[0]: Set PCI routing entry (2-21 -> 0xc9 -> IRQ 21 Mode:1 Active:1) 00:02:09[A] -> 2-21 -> IRQ 21 IOAPIC[0]: Set PCI routing entry (2-20 -> 0xd1 -> IRQ 20 Mode:1 Active:1) 00:02:09[D] -> 2-20 -> IRQ 20 IOAPIC[0]: Set PCI routing entry (2-18 -> 0xd9 -> IRQ 18 Mode:1 Active:1) 00:02:0e[A] -> 2-18 -> IRQ 18 number of MP IRQ sources: 15. number of IO-APIC #2 registers: 24. testing the IO APIC....................... IO APIC #2...... .... register #00: 02000000 ....... : physical APIC id: 02 ....... : Delivery Type: 0 ....... : LTS : 0 .... register #01: 00178020 ....... : max redirection entries: 0017 ....... : PRQ implemented: 1 ....... : IO APIC version: 0020 .... register #02: 00000000 ....... : arbitration: 00 .... register #03: 00000001 ....... : Boot DT : 1 .... IRQ redirection table: NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect: 00 000 00 1 0 0 0 0 0 0 00 01 001 01 0 0 0 0 0 1 1 39 02 000 00 1 0 0 0 0 0 0 00 03 001 01 0 0 0 0 0 1 1 41 04 001 01 0 0 0 0 0 1 1 49 05 001 01 0 0 0 0 0 1 1 51 06 001 01 0 0 0 0 0 1 1 59 07 001 01 0 0 0 0 0 1 1 61 08 001 01 0 0 0 0 0 1 1 69 09 000 00 1 0 0 0 0 0 0 00 0a 001 01 0 0 0 0 0 1 1 71 0b 001 01 0 0 0 0 0 1 1 79 0c 001 01 0 0 0 0 0 1 1 81 0d 001 01 0 0 0 0 0 1 1 89 0e 001 01 0 0 0 0 0 1 1 91 0f 001 01 0 0 0 0 0 1 1 99 10 001 01 1 1 0 1 0 1 1 C1 11 001 01 1 1 0 1 0 1 1 A9 12 001 01 1 1 0 1 0 1 1 D9 13 001 01 1 1 0 1 0 1 1 B9 14 001 01 1 1 0 1 0 1 1 D1 15 001 01 1 1 0 1 0 1 1 C9 16 001 01 0 1 0 1 0 1 1 A1 17 001 01 1 1 0 1 0 1 1 B1 IRQ to pin mappings: IRQ1 -> 0:1 IRQ2 -> 0:2 IRQ3 -> 0:3 IRQ4 -> 0:4 IRQ5 -> 0:5 IRQ6 -> 0:6 IRQ7 -> 0:7 IRQ8 -> 0:8 IRQ10 -> 0:10 IRQ11 -> 0:11 IRQ12 -> 0:12 IRQ13 -> 0:13 IRQ14 -> 0:14 IRQ15 -> 0:15 IRQ16 -> 0:16 IRQ17 -> 0:17 IRQ18 -> 0:18 IRQ19 -> 0:19 IRQ20 -> 0:20 IRQ21 -> 0:21 IRQ22 -> 0:22 IRQ23 -> 0:23 .................................... done. PCI: Using ACPI for IRQ routing PCI: if you experience problems, try using option 'pci=noacpi' or even 'acpi=off' Regards Marcel
Created attachment 2402 [details] patch for AE_NOT_ACQUIRED error please try the updated patch
Created attachment 2404 [details] debug patch that leaves fadt.sci_int at original value (same Debug patch as what David Shaohua Li just posted, except it prints out that it is doing something -- as all debug patches should do;-) What we think is happening is that IRQ9 is getting set up properly as pin 0-22, but that ACPI is later asking for IRQ22 because of this line of code. If this patch causes request_irq() for ACPI to work and ACPI events such as the power button work, then that confirms our understanding. (as willl the dmesg and /proc/interrupts output) The question then is if we should be calling this IRQ9 because it is an override of an ISA IRQ9, or IRQ22 because it is using APIC pin 22? In the past, of course, we've called it IRQ22. Linux, however, is inconsistent in this area. For example, the timer interrupt is labeled as IRQ0 because it is on the PIC IRQ0, but it is actually attached to IOAPIC INTIN 2, which would suggest it should be called IRQ2. So the consistent choices are IRQ2 + IRQ22 to name the APIC pin, or IRQ0 +IRQ9, to name the PIC IRQ input.
Created attachment 2415 [details] possible fix - ignore srcbus_irq on sci override, only gsi matters The problem with the earlier code is that it gave the name IRQ9 to pin 22. we really want this to be IRQ22 for pin 22, since other devices may share the IRQ and this is the name-space they'll use in their _PRT. Please apply this patch all by itself to the latest tree, do not apply the previous debug patches with this. I don't have a non-identity-mapped SCI on any testing hardware here, so all I could do was verify that this doesn't break the rest of the world. I have two questions/reservations about this patch. 1. source bus type for the SCI is always ISA for this method. dunno if that matters. 2. with level-sensitive trigger, setup_IO_APIC_irqs will initially mask the irq and rely on the irs_desc[irq].startup routine to unmask it later, and it wasn't obvious to me when that is called. So it is important to verify not only does this fix allow the systms in question to boot, but to verify that their SCI works eg. power button. If this doesn't work out, then I think plan B is to use the mp_override_legacy_irq() method only for irq < 16, and otherwise call io_apic_set_pci_routing() like we have in the past, and as we do for _PRT entries.
Created attachment 2416 [details] dmesg resulting from proposed fix from Trond Myklebust "Sweet... All appears to be working fine, and power button -> controlled poweroff."
Created attachment 2437 [details] dmesg from proposed fix -- interrupt storm on IRQ 21 and 22 from Marcel Holtmann (re: proposed fix) this still oopses for me and leaves the network card unusable and these are my interrupts
Created attachment 2446 [details] my dmesg (though it's wolk2.3 but it doesn't matter because of the same ACPI code) Hi Len, works for me now with the proposed fix. No problems so far since 2 days. ciao, Marc
Fixed in 2.6.5-rc3 Fixed in 2.4.26-rc1 Closing. Marcel's Asus turned out to also suffer from bug 2409 where eth0 and eth1 requested IRQ9 but drove IRQ21 and IRQ22.