ACPI Problems: IRQ conflicts on USB controllers and SATA
controller
Erik Norgaard
norgaard at locolomo.org
Fri Oct 13 17:01:37 UTC 2006
Thanks, I tried but no luck... :(
John Baldwin wrote:
> 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.
For boot-v with empty loader.conf:
interrupt total rate
irq1: atkbd0 410 1
irq9: acpi0 17173212 50959
irq14: ata0 1296 3
irq15: ata1 47 0
irq18: uhci0 uhci+ 2 0
irq22: fwohci0+ 1 0
cpu0: timer 673315 1997
Total 17848283 52962
>> 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.
Didn't get that...
>
>>>> 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.
That's what I understood from the documentation, but if both handles
IRQs then I don't understand how they can coexist.
>>>> 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.
OK, I tried this and have found two possible outcomes: System freezes
after GEOM: new disk ad0 or a fatal trap 19:
Fatal trap 19: non-maskable interrupt trap while in kernel mode
Instruction pointer = ...
Stack pointer = ...
frame pointer = ...
code segment = ...
processor eflags = interrupt enabled, resume, IOPL=0
current process = 34 (acpi_thermal)
trap number = 19
panic: non-maskable interrupt trap
This has happened with either acpi_thermal or acpi_task_0 as current
process. There is nothing that seem to determine how booting will fail.
The ASL is here: http://www.locolomo.org/src/acpi/custom.asl just in
case I messed up. What I understood from your description was that all
the IRQ declarations should be
IRQ (Level, ActiveLow, Shared) {1,3,4,5,6,7,10,11,14,15}
> 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.
Tried that but no change. I have added the dmesg etc to the same path as
the previous: http://www.locolomo.org/src/acpi/
Thanks for taking your time, Erik
--
Ph: +34.666334818 web: http://www.locolomo.org
X.509 Certificate: http://www.locolomo.org/crt/8D03551FFCE04F0C.crt
Key ID: 69:79:B8:2C:E3:8F:E7:BE:5D:C3:C3:B1:74:62:B8:3F:9F:1F:69:B9
More information about the freebsd-mobile
mailing list