Bug 1563

works with noacpi or noapic?
I noticed in test7, acpi irq is 9
but now it is 10, wield?
please attach dmesg when work or not, and correspond /proc/interrupt
many thanks.

Works with noapic. And yes, it's weird that it was irq 9 in test7 and irq 10
now. I might have done something in the bios. I'll check. But it still works
when I boot with noapic. Acpi is enabled all the time. I'll attache the dmesg's
and interrupt's.

Created attachment 1487 [details]
dmesg-2.6.0-test9-with-acpi

Created attachment 1488 [details]
interrupts-2.6.0-test9-with-acpi

Created attachment 1489 [details]
dmesg-2.6.0-test9-with-acpi-and-noapic

Created attachment 1490 [details]
interrupts-2.6.0-test9-with-acpi-and-noapic

I had obviously earlier tried to change some of the irq settings in BIOS to try
to get the kernel not to oops. Thus the change of interrupts. I now set
everything back to auto, without the powerbutton getting back to life. (ACPI now
has irq 9 again)

I guess when use apic, acpi will do a irq overide, like this line indicate:
>ACPI: INT_SRC_OVR (bus[0] irq[0x9] global_irq[0x9] polarity[0x0] trigger[0x0])
if this overide didn't do, acpi irq can't work.
but when use noapic, this overide is not necessary. 
when you change your BIOS to set acpi irq to 10, MADT can't change with it. so 
use apic leads to error.
maybe this is BIOS error too.

I can't set ACPI irq, I can set the irqs for the different pci-slots. When I set
the irq for one of them to 9, acpi got irq 10. Now I have every pci-slot set to
"auto" and ACPI is back to irq 9, but it still doesn't work. Anyway, should I
just close this bug and forget about it?

Created attachment 1499 [details]
patch for this error

It's a bug indead. Please try this patch. Thanks

Created attachment 1502 [details]
/proc/interrupts after patch

Hmm. This patch didn't make the power-button work, but my interrupts changed.
Now they look just the same as I just found out they do in XP (look at my other
bug, Len Brown asked for it). The power button works just fine in XP.

Anyway, here's a new /proc/interrupts (which looks more sane, but still doesn't
make my powerbutton work):

More hints?

At least we fixed an error.:) But to why acpi can't work, I have no idea now.
maybe we can try change acpi irq polarity, just a guess.

Tell me how, and I'll try it right away :)

in mpparse.c line:1087
>io_apic_set_pci_routing(ioapic, ioapic_pin, irq,
                         (flags.trigger >> 1) , (flags.polarity >> 1));
change to:
io_apic_set_pci_routing(ioapic, ioapic_pin, irq,0,0);
or, io_apic_set_pci_routing(ioapic, ioapic_pin, irq,0,1);
or, io_apic_set_pci_routing(ioapic, ioapic_pin, irq,1,0);
or, io_apic_set_pci_routing(ioapic, ioapic_pin, irq,1,1);
which one can work?

The BIOS tells us to set the ACPI SCI to IRQ9, level-high, edge triggered: 
 
ACPI: INT_SRC_OVR (bus[0] irq[0x9] global_irq[0x9] polarity[0x0] trigger[0x0]) 
 
and linux does exactly that: 
IOAPIC[0]: Set PCI routing entry (2-9 -> 0x71 -> IRQ 9 Mode:0 Active:0) 
 
.... IRQ redirection table: 
 NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect: 
 09 003 03  0    0    0   0   0    1    1    71 
 
Looks like you've got power button configured okay: 
ACPI: Power Button (FF) [PWRF] 
 
Hmm, maybe a VIA-specific chipset issue here. 
 
can you attach the output from "lspci -v" so we can see the PCI-IDs and verify which _PRT 
entries are used by which devices?  If Windows doesn't need a fixed DSDT to run on this box, 
Linux shouldn't either... 
 
If you find that acpi is attached to IRQ10, and the OVR line above doesn't say global_irq 0xa, 
then it is a (linux) bug.  Is is possible that the BIOS changes the MADT between IRQ9 and IRQ 
10 depending on the CMOS settings you select.  This would show up in a changed acpidmp 
output and a changed dmesg OVR lines in dmesg. 
 
Re: IRQ27 -- yes, that sure looks broken, as this IOAPIC has only 24 entries;-) 
 

Shaohua:

Both polarity 0,1 and 1,1 works perfect. ACPI changes from IO-APIC-edge to
IO-APIC-level with this change. Now my box works perfect :):) Will it be
possible to make this autodetected? Because now everything is just perfect, for
the first time ever :)

Len:

With Shaohua's patch, this is now gone, and the irq's are excactly the same as
with Windows :) Of course it would be very, very, very nice if I don't have to
use my own dsdt, and patch the kernel. So if you'd make ACPI work with my DSDT,
you really are my hero :) I'll attach lspci shortly. And yes, Windows seems to
get everything right. I didn't use it much, but ACPI, lan and usb at least
worked right.

Created attachment 1506 [details]
/proc/interrupts with polarity set to 1,1

Created attachment 1507 [details]
lspci -v

>Will it be possible to make this autodetected?
As Len said, your MADT said ACPI irq should be IO-APIC-edge, but it can't work.

I know I'm a pain in the ass now, but XP get's it right... :)

yes, ACPI irq hard code to use polarity 1,1 before, but some systems broken. 
we change to set ACPI irq polarity according to MADT. But now your system 
broken with the change. :( 

Len, should we add it in dmiscan?

> Both polarity 0,1 and 1,1 works perfect. 
 
io_apic_set_pci_routing(ioapic, ioapic_pin, irq,0,1) 
	is edge trigger, active low 
 
io_apic_set_pci_routing(ioapic, ioapic_pin, irq,1,1) 
	is level trigger, active low 
 
In /proc/interrupts you should see  
  9:          0          0   IO-APIC-edge  acpi 
and 
  9:          0          0   IO-APIC-level  acpi 
respectively. 
and the polarity is shown in the dmesg on the IOAPIC RTE entry line for irq 9.  
 
The BIOS is explicitly telling us to use 0,0 -- edge trigger, active high. 
If we don't do what the BIOS tells us to do, then we break on all 
the systems with a correct BIOS.  I'm really quite perplexed at how 
Windows isn't stumped on this one too. 
Blacklist is out -- this system is too obscure.  I wonder if there 
is a VIA chip-set specific quirk we're missing...  We could resort 
to a boot parameter over-ride, but I don't see as yet an automatic 
way to address this system. 
 
 

Len:

Yes, you're right. With polarity 0,1 I get edge trigger, with 1,1 I get level
trigger.

I'm sorry that you don't have any idea how to make this work, but I'm thankful
for both of you looking so much into this :) Isn't there a way to find out what
polarity XP uses? Or something..?

Stian, 
Please undo the mpparse.c edit and apply the patch in bug #1351 
Turns out that polarity[0x0] trigger[0x0] doesn't mandate (high, edge), 
it specifies (default, default) and we assumed that meant high/edge... 
 
thanks, 
-Len 
 

Thanks, I'll try as soon as I get to the box again (18th december). But I guess
this solves it :) Great work :)

I should mention also that the "official" fix for the IRQ27 issue is in bug #1570 
 

Great. Thanks :)

With acpi20031203 patch, and my latest beta bios from Rioworks, everything acpi
related (maybe except poweroff, has to test more to see if it shuts down every
time (but that's another bug)) works perfect :) Thank you all for your great
work, it's really, really appreciated!

Uhh, sorry about that verified-thing.