Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 13 Oct 2006 18:58:46 +0200
From:      Erik Norgaard <norgaard@locolomo.org>
To:        John Baldwin <jhb@freebsd.org>
Cc:        freebsd-mobile@freebsd.org
Subject:   Re: ACPI Problems: IRQ conflicts on USB controllers and SATA controller
Message-ID:  <452FC5C6.1080304@locolomo.org>
In-Reply-To: <200610121606.22200.jhb@freebsd.org>
References:  <452E3E0B.6040709@locolomo.org> <200610121501.48116.jhb@freebsd.org> <452E9DA7.9050008@locolomo.org> <200610121606.22200.jhb@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?452FC5C6.1080304>