ACPI Problems: IRQ conflicts on USB controllers and SATA controller

[John Baldwin]

On Thursday 12 October 2006 15:55, Erik Norgaard wrote:
> John Baldwin wrote:
> > On Thursday 12 October 2006 12:42, Erik Norgaard wrote:
> >> I have dumped dmesg and other stuff with different options at boot, 
> >> since this is pretty verbose I've placed it on my website:
> >>
> >> boot -v:
> >>
> >> http://www.locolomo.org/src/acpi/dmesg-GENERIC-v
> >> http://www.locolomo.org/src/acpi/sysctl-GENERIC-v
> >> http://www.locolomo.org/src/acpi/pciconf-GENERIC-v
> >> http://www.locolomo.org/src/acpi/lspci-GENERIC-v
> >> http://www.locolomo.org/src/acpi/vmstat-GENERIC-v
> > 
> > Nothing here looks wrong.  Can you break into the debugger when the box
> > locks up?
> 
> The box freezes when apic is disabled but pci_link is enabled. In the 
> above case, both apic and pci_link are enabled, this sucks out resources 
> of the box with 85% cpu on interrupt handling.

Ok, so get vmstat -i output.  There's not much flexibility here though as all 
the APIC IRQ's are hardcoded, so to guess which ones are routed incorrectly 
will be a pain.

> I will try to see if I can get the debugger when apic is disabled and 
> pci_link enabled.

Actually, I think I know what that is already.

> >> boot -v, acpi disabled:
> > 
> > Doesn't detect APIC.  BIOS is too dumb to provide $PIR.  That's a new
> > low for incompetence on the part of BIOS writers.
> 
> Strange - is ACPI required on this box to find APIC? Sounds wierd when 
> they are both enabled they each seem to fight for control over the 
> devices...

ACPI and APIC are two _entirely_ different things.  On your box, yes, ACPI is 
required to find APICs.

> >> boot -v, apic disabled:
> >>
> >> http://www.locolomo.org/src/acpi/dmesg-GENERIC-v-no_apic
> > 
> > The problem here is (again) really stupid BIOS writers.  Maybe they can't
> > read.  Edit your ASL to change the resources to say that IRQ 10 (which
> > the BIOS assigns) is ok instead of IRQ 11.  You can probably get by just
> > with fixing LNKD's resource:
> > 
> >                 Device (LNKD)
> >                 {
> >                     Name (_HID, EisaId ("PNP0C0F"))
> >                     Name (_UID, 0x04)
> >                     Method (_DIS, 0, Serialized)
> >                     {
> >                         Store (0x80, PDRC)
> >                     }
> > 
> >                     Name (_PRS, ResourceTemplate ()
> >                     {
> >                         IRQ (Level, ActiveLow, Shared) 
> > {1,3,4,5,6,7,11,12,14,15}
> >                     })
> > 
> > Replace the '11' here with '10' and update it.  In fact, you should
> > fix the ones with IRQ's '10' and '12' to list '10' and '11' instead
> > and the ones with '11' and '12' to list '10' and '11' instead.
> > 
> > 12 is used by your PS/2 mouse/trackpad, so it isn't suitable.
> 
> Thanks I will try that. I'm new on this, will loading a custom ASL 
> overwrite the existing permanently? I mean, I'm kind of worried that I 
> mess up and have a box that can't boot at all.

No, you load it from the loader and the kernel just uses the one you load 
instead of the one from the BIOS.  Check acpi(4) more.

> Secondly, I see there is nothing on IRQ9 in the ASL, yet I have an 
> interrupt storm on IRQ9 also, should 9 be added to the list above?

No.

> Finally, previously I solved the interrupt storm on IRQ5 by setting 
> hw.pci6.10.INTA.irq=5 in the loader.conf, can this be corrected in the 
> ASL also?

You really shouldn't use that hint, you should route an entire link 
(hw.pci.link.LNKD.irq = 5 for example) when using links.  First try just 
fixing your ASL w/o using any settings in loader.conf.

Hmm, you can also try just doing this w/o having to hack your ASL which might 
fix things:

hw.pci.link.LNKB.irq=10
hw.pci.link.LNKD.irq=10
hw.pci.link.LNKF.irq=10

It will emit warnings about the IRQs not being valid but still use them, and 
this matches what your BIOS used.

-- 
John Baldwin