When running 2.4.21 on the same machine, pressing the power button generates an appropriate event on /proc/acpi/event. With 2.6.0-test6: no kernel message and nothing reaching a "cat /proc/acpi/event".
Created attachment 1036 [details] kernel message log
Created attachment 1037 [details] lcpci -vv output
Created attachment 1038 [details] /proc/interrupts
Created attachment 1039 [details] dmidecode output
Created attachment 1040 [details] acpidmp output
Forgot to mention that I use two patches: * acpi-20030918-2.6.0-test (problem occurs without this patch as well) * the fix from bug#678
Tried with the new kernel (test8, again with fix from bug#678) -- same story.
Can you re-produce this with the latest 2.4.23 or 2.6.0? (without any patches applied) Unclear to me why the patch from bug #678 would make a difference on this box, does it? (any chance you could attach the dmesg and /proc/interrupts before and after?) It appears we're setting up the SCI as the platform requested: ACPI: INT_SRC_OVR (bus[0] irq[0x9] global_irq[0x9] polarity[0x0] trigger[0x0]) IOAPIC[0]: Set PCI routing entry (2-9 -> 0x71 -> IRQ 9 Mode:0 Active:0) 9: 0 IO-APIC-edge acpi and it looks like CONFIG_ACPI_BUTTON is enabled: ACPI: Power Button (FF) [PWRF] I don't suppose you can get the dmesg and /proc/interrupts from 2.4.21 when ACPI events worked on this machine? Lastly, can you verify that ACPI interrutps work if you boot with "noapic" If that works then we know this is IO-APIC related rather than related to something else. thanks, -Len
I tested 2.6.0-test9. This version does not need the fix for #678 anymore. But no button events, still. "noapic" did the trick, though! I don't think the apic was used in my 2.4.21 kernel -- that may explain why it always worked with that.
Created attachment 1445 [details] /proc/interrupts when using noapic
Using "noapic" acpi gets the same interrupt line as before (see attachments). I noticed though, that with this option pressing the power button would increment the counter of interrupt 9 by one. When using the apic on the other hand, the counter stays at zero, nor are other interrupts (except timer and i8042) raised.
Can you attach the dmesg and /proc/interrupts from booting with "pci=noacpi" and report if ACPI SCI events work? It would be good to know if MPS is able to program the IOAPIC correctly. Without any cmdline parameters, it would be good to know if ACPI can be forced to program the SCI in a mode that will work. Please edit arch/i386/kernel/mpparse.c, and at the bottom of mp_config_ioapic_for_sci(), in 4 experiments, please replace the call to io_apic_set_pci_routing() with the following 4 hard-coded options and report back if ACPI interrupts work in APIC mode: io_apic_set_pci_routing(ioapic, ioapic_pin, irq, 1, 1); // Level, Low io_apic_set_pci_routing(ioapic, ioapic_pin, irq, 0, 1); // Edige, Low io_apic_set_pci_routing(ioapic, ioapic_pin, irq, 1, 0); // Level, High io_apic_set_pci_routing(ioapic, ioapic_pin, irq, 0, 0); // Edge, High thanks, -Len
Created attachment 1557 [details] acpidmp on EPOX_8K9A9I
Created attachment 1558 [details] interrupts with noapic on EPOX 8K9A9I
Created attachment 1559 [details] dmidecode on EPOX 8K9A9I
Created attachment 1560 [details] lspci -vv on EPOX 8K9A9I
Created attachment 1561 [details] dmesg on EPOX 8K9A9I
Comment on attachment 1557 [details] acpidmp on EPOX_8K9A9I using kernel 2.6.0-test11
Created attachment 1562 [details] interrupts with io-apic on EPOX 8K9A9I
I am using kernel 2.6.0-test11 and with "noapic" the acpi button works. With apic there are the same problems as described above (no events in /proc/acpi/event, no interrupt 9 triggered if button pressed) I will try with editing arch/i386/kernel/mpparse.c now...
Okay, i tested changing io_apic_set_pci_routing: 1, 1 // Level, Low --- works 0, 1 // Edge, Low --- works 1, 0 // Level, High --- fails 0, 0 // Edge, High --- fails What shall I do now? Is it safe to have 1, 1 enabled in kernel by default or would that interfere with something else, too?
I just tried 2.6.0-test11 with the four different changes to io_apic_set_pci_routing, and encountered the same effects as Claas: polarity==low works, regardless of whether level or edge is chosen. FWIW, my motherboard is an EPoX 8K9AI, which is similar to Claas's but has a different southbridge (c.f. lspci output).
With "pci=noacpi" event interrupts do not work either. dmesg and /proc/interrupts coming up.
Created attachment 1568 [details] dmesg with "pci=noacpi"
Created attachment 1569 [details] /proc/interrupts with "pci=noacpi"
I think this is not really important, but my EPOX 8K9A9I is Rev. 1.0 and I bought it in mid July 2003.
EPOX 8K9A9I: ACPI: APIC (v001 KT400A AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x(nil) ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) ACPI: IOAPIC (id[0x02] address[0xfec00000] global_irq_base[0x0]) ACPI: INT_SRC_OVR (bus[0] irq[0x0] global_irq[0x2] polarity[0x0] trigger[0x0]) ACPI: INT_SRC_OVR (bus[0] irq[0x9] global_irq[0x9] polarity[0x0] trigger[0x0]) ACPI: INT_SRC_OVR (bus[0] irq[0xe] global_irq[0xe] polarity[0x1] trigger[0x1]) ACPI: INT_SRC_OVR (bus[0] irq[0xf] global_irq[0xf] polarity[0x1] trigger[0x1]) ACPI: LAPIC_NMI (acpi_id[0x00] polarity[0x1] trigger[0x1] lint[0x1]) Unless we're somehow decoding the MADT wrong, the BIOS on this box is also explicitly requesting the SCI on IRQ9 to be level HIGH, EDGE triggered. But your experiments show that it works only if set to level LOW. Curious that this Epox is also requesting that IRQ14 and IRQ15 be LEVEL, LOW -- but we're not doing that: 14: 4864 IO-APIC-edge ide0 15: 33 IO-APIC-edge ide1 This is probably a bug, and if fixed we'd probably break Epox IDE too! This patch, missing from 2.6.0, will give us dmesg that tells us exactly how the IOAPIC is programmed in ACPI mode -- though I don't expect any surprises, I'm low on ideas and observations on how to fix this one... http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/patches/test/2.6.0-test9/20031107182100-print_IO_APIC.patch BTW. the reason this broke since 2.4.21 is that we used to hard-code the ACPI SCI to LEVEL/LOW. But we found that broke a bunch of machines which specified otherwise using an explicit INT_SRC_OVR -- like this one. Here we seem to be failing by doing exactly what the BIOS requests -- unclear how to fix those machines and this one at the same time... Re: Robert's pci=noacpi results NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect: 09 001 01 0 0 0 0 0 1 1 69 Looks like MPS puts IRQ 9 in EDGE/HIGH mode -- just like ACPI does. Class, you mentioned in e-mail that "noapic" works. does apic mode with "pci=noapic" behave like Robert's Epox? I'm really curious if Windows 2K or XP can run this box in APIC mode and still get ACPI events -- any chance you can check? thanks, -Len
Created attachment 1570 [details] patch to set APIC ACPI SCI OVR default to level/low The SCI over-ride flags here don't specify edge/high -- they specify default/default. We assumed that means edge/high -- like the other ISA interrupts. On the other hand, the ACPI spec says that SCI should be level/low -- so maybe using that as the default unless requested otherwise is the way to go. Please try the attached patch. Thanks, Len.
EPOX 8K9A9I: >you mentioned in e-mail that "noapic" works. >does apic mode with "pci=noapic" behave like Robert's Epox? Well, I only appended "noapic" and not "pci=noapic". But i can try that, too. >I'm really curious if Windows 2K or XP can run this box in APIC mode >and still get ACPI events -- any chance you can check? I can't check with Windows 2000 or XP, I don't have that. Maybe Robert can check with windows.
Created attachment 1571 [details] interrupts with the two patches mentioned above (on EPOX 8K9A9I)
Created attachment 1572 [details] dmesg with the two patches mentioned above (on EPOX 8K9A9I)
I tried with the two patches mentioned above: ACPI works. Besides, I can see no difference between "noapic" and "pci=noapic". -- claas
Claas, Thanks for verifying ACPI again works with this patch applied. ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 dfl dfl) IOAPIC[0]: Set PCI routing entry (2-9 -> 0x71 -> IRQ 9 Mode:1 Active:1) NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect: 09 001 01 0 1 0 1 0 1 1 71 The default for an SCI OVR that doesn't specify trigger mode is now LEVEL, and the default polarity is LOW. Hopefully other systems that specify an over-ride with defaults will work this way also. Re: pci=noapic Typo on my part, I meant "pci=noacpi" -- though this is an academic experiment at this point if ACPI is configuring interrupts properly. I'm going to add a synonym for this "acpi_irq=off" some day... Re: IDE Forget what I said earlier, the overrides for IDE are unnecessary, but correct. I mis-read the numeric values in the previous comment, the new code presents this info more clearly to us humans: ACPI: INT_SRC_OVR (bus 0 bus_irq 14 global_irq 14 high edge) ACPI: INT_SRC_OVR (bus 0 bus_irq 15 global_irq 15 high edge)
Hello Len, great job, thanks. I hope this patch will make it into the next 2.6.0-test-kernel really soon. regards, claas
Hello, as far as I see, the bug still exists in 2.6.1-rc1. Len, why didn't it make into the kernel? Could you please comit that patch? regards, claas
in 2.6.2-rc3 -- closing.