After I just got a fixed DSDT for my motherboard (Rioworks SDVIA) from Shaohua Li, everything on my MB finally started working as it should :) (see bug http://bugme.osdl.org/show_bug.cgi?id=1164 ) But the power-button doesn't generate any ACPI-events. If I boot with noapic, the power-button works just fine.
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.