Bug 1351

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.