Skip site navigation (1)Skip section navigation (2) 
Date:      Tue, 16 Nov 2004 15:38:51 -0800
From:      Nate Lawson <nate@root.org>
To:        Andrew Gallatin <gallatin@cs.duke.edu>
Cc:        John Baldwin <jhb@FreeBSD.org>
Subject:   Re: New ACPI PCI Link Routing code
Message-ID:  <419A8F8B.3050206@root.org>
In-Reply-To: <16794.36113.628156.440391@grasshopper.cs.duke.edu>
References:  <200411111737.00537.jhb@FreeBSD.org> <200411161339.13818.jhb@FreeBSD.org> <16794.28367.159895.3565@grasshopper.cs.duke.edu> <200411161647.14543.jhb@FreeBSD.org> <16794.33094.416989.88341@grasshopper.cs.duke.edu>	<419A8B75.4060000@root.org> <16794.36113.628156.440391@grasshopper.cs.duke.edu>
next in thread | previous in thread | raw e-mail | index | archive | help 
Andrew Gallatin wrote:
> Nate Lawson writes:
>  > 
>  > You'll need ASL to debug this, acpidump -t -d > trinity.asl
>  > It seems very surprising that _CRS would return 3 interrupts.  I'm 
>  > guessing the first is the active one?
> 
> http://people.freebsd.org/~gallatin/trinity.asl

         Name (IRTP, ResourceTemplate ()
         {
             IRQ (Level, ActiveLow, Shared) {0}
         })
         CreateWordField (IRTP, 0x01, INTP)
         Name (IRTA, ResourceTemplate ()
         {
             Interrupt (ResourceConsumer, Level, ActiveLow, Exclusive)
             {
                 0x00000000,
             }
         })
         CreateDWordField (IRTA, 0x05, INTA)
         Method (GETI, 1, NotSerialized)
         {
             If (And (Arg0, 0x0F, Local0))
             {
                 Return (Local0)
             }
             Else
             {
                 Return (\MLIB.CNV2 (And (Arg0, 0x0F)))
             }
         }
         Device (LN00) {
             Method (_CRS, 0, NotSerialized)
             {
                 Store (GETI (PI00), INTP)
                 Return (IRTP)
             }

Um, what a weird system.  This link is used for both APIC and PIC mode 
but only returns the PIC settings via _CRS (IRTP).  To generate the _CRS 
result, it creates a word field (2 bytes) at the start of IRTP + 2 
bytes.  It then overwrites this IRQ template with the current setting, 
retrieved from an IO port specified by PI00.

Still, IRTP only has one IRQ template so the KASSERT should be 
incorrect.  It may make sense to hexdump the interrupt object returned. 
  Perhaps the Word field is at the wrong offset or wrong size and so it 
overwrites the IRQ template with some bogus value.

-- 
Nate

Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?419A8F8B.3050206>