problems with PRT and PCI routing table

problems with PRT and PCI routing table

[Holger W.]

[-- Attachment #1: Type: text/plain, Size: 2285 bytes --]

Hi everybody,

I've got some serious problems with ACPI and the IRQ mapping for my devices. (look at my
postings "mpparse.c APIC/ACPI support" and "APIC, USB mouse and errors").
It seems that not all devices get the IRQs they should regarding the PRT table. I've verified it
and it seems that the table is all right (attachment "PRT_table.txt"). Especially the devices
00:00:10, 00:00:11 and 00:00:12 which point to "\_SB_.PCI0.ALKx[0]" (x=A..D) don't get the
interrupts they should regarding the table.

There's perhaps a problem in "acpi_pci_link_add" (pci_link.c), because the function returns ...

<4>ACPI: PCI Interrupt Link [ALKA] (IRQs 20, disabled)
<4>ACPI: PCI Interrupt Link [ALKB] (IRQs 21, disabled)
<4>ACPI: PCI Interrupt Link [ALKC] (IRQs 22, disabled)
<4>ACPI: PCI Interrupt Link [ALKD] (IRQs 23, disabled)

... or "acpi_pci_link_get_current" (pci_link.c) has got a problem ? ...

<4>pci_link-0252 [18] acpi_pci_link_get_curr: No IRQ resource found
<4>pci_link-0252 [20] acpi_pci_link_get_curr: No IRQ resource found
<4>pci_link-0252 [22] acpi_pci_link_get_curr: No IRQ resource found
<4>pci_link-0252 [24] acpi_pci_link_get_curr: No IRQ resource found

I don't know which function I should "blame" - I only know that everything works fine for LNKA-D
but not for ALKA-D:

<4>ACPI: PCI Interrupt Link [LNKA] (IRQs 1 3 4 5 6 7 10 *11 12 14 15)
<4>ACPI: PCI Interrupt Link [LNKB] (IRQs 1 3 4 5 6 7 *10 11 12 14 15)
<4>ACPI: PCI Interrupt Link [LNKC] (IRQs 1 3 4 5 6 7 10 11 *12 14 15)
<4>ACPI: PCI Interrupt Link [LNKD] (IRQs 1 3 4 5 6 7 10 11 12 *14 15)

So this causes a lot of linked errors. First of all I get a lot of "<7>Pin 2-xx already
programmed" (mp_parse_prt / mpparse.c) messages. Next, "acpi_pci_irq_lookup" (pci_irq.c) fails
because it can't find the PRT entries and "acpi_pci_link_get_irq", "acpi_pci_irq_lookup" and
"acpi_pci_irq_derive" also fail.
And finally "eisa_set_level_irq" is not called in "acpi_pci_irq_enable" which results in
non-functional devices which require a "level" trigger mode.

So could one of the hardware experts pleeeeease help me ???

MANY MANY MANY THANKS in advance,

HOLGER W.

P.S.: if you need more information about my boot messages or sth. similar - feel free to ask for
it !!!

[-- Attachment #2: PRT_table.txt --]
[-- Type: text/plain, Size: 1852 bytes --]

<7>ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
<4>PRT entry:   00:00:08[A] -> [16]
<4>PRT entry:   00:00:08[B] -> [17]
<4>PRT entry:   00:00:08[C] -> [18]
<4>PRT entry:   00:00:08[D] -> [19]
<4>PRT entry:   00:00:09[A] -> [17]
<4>PRT entry:   00:00:09[B] -> [18]
<4>PRT entry:   00:00:09[C] -> [19]
<4>PRT entry:   00:00:09[D] -> [16]
<4>PRT entry:   00:00:0A[A] -> [18]
<4>PRT entry:   00:00:0A[B] -> [19]
<4>PRT entry:   00:00:0A[C] -> [16]
<4>PRT entry:   00:00:0A[D] -> [17]
<4>PRT entry:   00:00:0B[A] -> [19]
<4>PRT entry:   00:00:0B[B] -> [16]
<4>PRT entry:   00:00:0B[C] -> [17]
<4>PRT entry:   00:00:0B[D] -> [18]
<4>PRT entry:   00:00:0C[A] -> [18]
<4>PRT entry:   00:00:0C[B] -> [19]
<4>PRT entry:   00:00:0C[C] -> [16]
<4>PRT entry:   00:00:0C[D] -> [17]
<4>PRT entry:   00:00:0D[A] -> [19]
<4>PRT entry:   00:00:0D[B] -> [16]
<4>PRT entry:   00:00:0D[C] -> [17]
<4>PRT entry:   00:00:0D[D] -> [18]
<4>PRT entry:   00:00:0E[A] -> [17]
<4>PRT entry:   00:00:0E[B] -> [18]
<4>PRT entry:   00:00:0E[C] -> [19]
<4>PRT entry:   00:00:0E[D] -> [16]
<4>PRT entry:   00:00:10[A] -> \_SB_.PCI0.ALKB[0]
<4>PRT entry:   00:00:10[B] -> \_SB_.PCI0.ALKB[0]
<4>PRT entry:   00:00:10[C] -> \_SB_.PCI0.ALKB[0]
<4>PRT entry:   00:00:10[D] -> \_SB_.PCI0.ALKB[0]
<4>PRT entry:   00:00:11[A] -> \_SB_.PCI0.ALKA[0]
<4>PRT entry:   00:00:11[B] -> \_SB_.PCI0.ALKB[0]
<4>PRT entry:   00:00:11[C] -> \_SB_.PCI0.ALKC[0]
<4>PRT entry:   00:00:11[D] -> \_SB_.PCI0.ALKD[0]
<4>PRT entry:   00:00:01[A] -> [16]
<4>PRT entry:   00:00:01[B] -> [17]
<4>PRT entry:   00:00:01[C] -> [18]
<4>PRT entry:   00:00:01[D] -> [19]
<4>PRT entry:   00:00:12[A] -> \_SB_.PCI0.ALKD[0]
<4>PRT entry:   00:00:12[B] -> \_SB_.PCI0.ALKD[0]
<4>PRT entry:   00:00:12[C] -> \_SB_.PCI0.ALKD[0]
<4>PRT entry:   00:00:12[D] -> \_SB_.PCI0.ALKD[0]

RE: problems with PRT and PCI routing table

[Holger W.]

I have to correct myself again. Let me see if I understood everything ...

First of all my PCI interrupt links are detected and I get messages like "ACPI: PCI Interrupt
Link [ALKA] (IRQs 20, disabled)". "Disabled" means in this special case that we have to
choose/enable an IRQ later.

Now "acpi_pci_irq_init" is called and we have the following calling-structure ...

acpi_irq_init {
  -> acpi_pci_link_check -> acpi_pci_link_set
  -> mp_parse_prt
  -> iosapic_parse_prt
  -> acpi_pci_irq_enable
}

"acpi_pci_link_check" will check all my devices for valid IRQs. In my special case it tries to
find an IRQ for my interrupt link ALKA. Because we don't have more than one IRQ (20) for ALKA,
we don't have a big choice. The attempt to set the IRQ for the link is done by
"acpi_pci_link_set".

Now we're here:

acpi_pci_link_set {
  -> acpi_set_current_resources
  -> acpi_bus_get_status
  -> acpi_pci_link_get_current
}

Everything works fine at this point up to "acpi_pci_link_get_current". And now we're one more
step further ...

acpi_pci_link_get_current {
  -> acpi_bus_get_status
  -> acpi_walk_resources -> acpi_pci_link_check_current
}

And after "acpi_walk_resources" ist the point where we fail. The condition "if (!irq)" is true
because "acpi_pci_link_get_current" returns with the error "pci_link-0262 [21]
acpi_pci_link_get_curr: No IRQ resource found".
That is we have an error in "acpi_pci_link_set" and we will return with this code fragment to
"acpi_pci_link_check":

result = acpi_pci_link_get_current(link);
if (result) {
	return_VALUE(result);
}

Because we failed in "acpi_pci_link_get_current" the irq variable is NULL and we get a message
like "ACPI: PCI Interrupt Link [ALKA] enabled at IRQ 0".

Now we're back in "acpi_pci_irq_init". Another problem could be located in "mp_parse_prt":

/* We're only interested in static (non-link) entries. */
if (entry->link.handle)
	continue;

I don't understand why only non-link entries are being used !

However, all side effects I mentioned in the last posting will occur due to these errors ...
I hope I now analyzed the code properly. Would be nice if some developers could comment :-)

Thanks for your attention !!!

HOLGER W.



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

RE: problems with PRT and PCI routing table

[Grover, Andrew]

> From: Holger W. [mailto:info-IGm5bqYn3xwb1SvskN2V4Q@public.gmane.org] 
> I have to correct myself again. Let me see if I understood 
> everything ...
> 
> First of all my PCI interrupt links are detected and I get 
> messages like "ACPI: PCI Interrupt
> Link [ALKA] (IRQs 20, disabled)". "Disabled" means in this 
> special case that we have to
> choose/enable an IRQ later.

Yes.

[code walkthru deleted]

> result = acpi_pci_link_get_current(link);
> if (result) {
> 	return_VALUE(result);
> }
> 
> Because we failed in "acpi_pci_link_get_current" the irq 
> variable is NULL and we get a message
> like "ACPI: PCI Interrupt Link [ALKA] enabled at IRQ 0".

Why did pci_link_get_current() fail? The ASL should report back 20 in
the extended irq structure, we should read that, and then that should be
that. I've heard a report that Windows does not use _CRS like we do, so
this ASL code path may be untested, and therefore that could be the
problem. Have you disassembled your ASL? What does this link device's
_CRS method look like?

> Now we're back in "acpi_pci_irq_init". Another problem could 
> be located in "mp_parse_prt":
> 
> /* We're only interested in static (non-link) entries. */
> if (entry->link.handle)
> 	continue;

My understanding (not 100%) is that in that particular section of the
code we are just dealing with the static _PRT entries, because the
dynamic ones are enumerated as link devices and handled through the code
paths you detailed in your message.

Regards -- Andy

The current PCI IRQ routing code was hashed out more than a year ago and
I think may be due for a rework. Persistent IRQ routing problems are
still occurring.

The current code:

1) Sees if there is a current IRQ for the link device, and uses that,
even if it is not in the range of IRQs listed in _PRS
2) For disabled link devices, it picks one according to a weighting
system and sets it.

Later on, a device driver will load and try to enable its irq. If we can
derive the irq, then great, but if we can't is when things start falling
apart.

Regards -- Andy


-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en

RE: problems with PRT and PCI routing table

[Holger W.]

[-- Attachment #1: Type: text/plain, Size: 1662 bytes --]

> that. I've heard a report that Windows does not use _CRS like we do, so
> this ASL code path may be untested, and therefore that could be the
> problem. Have you disassembled your ASL? What does this link device's
> _CRS method look like?

Hi Andrew,

you'll find the whole disassembly attached ... I had to do it with the Windows version of "iasl"
because the Linux version causes a "segmentation fault" on my system :(
I'm a bloody ACPI beginner so I don't really understand the _CRS method (which you'll find at
the end of this posting) - perhaps the ASL code is more useful for you :-)

Regards,

HOLGER W.

--

	Method (_CRS, 0, NotSerialized)
	{
	    Name (B37A, ResourceTemplate ()
	    {
		IRQ (Level, ActiveLow, Shared) {}
	    })
	    CreateByteField (B37A, 0x01, IRB1)
	    CreateByteField (B37A, 0x02, IRB2)
	    Name (B47A, ResourceTemplate ()
	    {
		Interrupt (ResourceConsumer, Level, ActiveLow, Shared)
		{
		    0x00000000,
		}
	    })
	    If (LNot (LEqual (DEID, 0x3177)))
	    {
		If (LNot (LEqual (DEID, 0x3147)))
		{
		    Return (B37A)
		}
		Else
		{
		    Return (B47A)
		}
	    }
	    Else
	    {
		Return (B47A)
	    }

	    Store (0x00, Local3)
	    Store (0x00, Local4)
	    And (PIRA, 0xF0, Local1)
	    ShiftRight (Local1, 0x04, Local1)
	    If (LNot (LEqual (Local1, 0x00)))
	    {
		If (LGreater (Local1, 0x07))
		{
		    Subtract (Local1, 0x08, Local2)
		    ShiftLeft (One, Local2, Local4)
		}
		Else
		{
		    If (LGreater (Local1, 0x00))
		    {
			ShiftLeft (One, Local1, Local3)
		    }
		}

		Store (Local3, IRB1)
		Store (Local4, IRB2)
	    }
	}

[-- Attachment #2: dsdt_AWRDACPI.zip --]
[-- Type: application/octet-stream, Size: 9765 bytes --]

RE: problems with PRT and PCI routing table

[Grover, Andrew]

Hi,

Referencing the ASL below, I believe the ASL is wrong.

Specifically the sequence should be:

1) Create IRQ resource template(s)
2) Fill in IRQ information
3) Return resource template

However, the below ASL appears to have #2 *after* an if/else that
returns the empty template. In addition, the code that does #3 only
seems to fill in the IRQ template, not the Interrupt template. (you use
the IRQ template to return IRQs <= 15, the Interrupt template for irqs
>15.)

So, the correct thing would be for the BIOS to properly implement this
_CRS method. However, we can assume that Windows is not using _CRS like
we are, so therefore to avoid this problem (and others on other
machines) perhaps we should redo the code to not rely on _CRS so much -
perhaps if CRS is zero, then we need to assign an IRQ from one of the
possibilities (obtained from _PRS).

Also, the current policy does not reassign the IRQ even if _CRS is not
listed in _PRS. It might be interesting to see if that should be
changed.

None of this really helps you in the immediate term, sorry...

> you'll find the whole disassembly attached ... I had to do it 
> with the Windows version of "iasl"
> because the Linux version causes a "segmentation fault" on my 
> system :(

Is this repeatable, if you compile it yourself from the acpica-unix
package?

Regards -- Andy

> 	Method (_CRS, 0, NotSerialized)
> 	{
> 	    Name (B37A, ResourceTemplate ()
> 	    {
> 		IRQ (Level, ActiveLow, Shared) {}
> 	    })
> 	    CreateByteField (B37A, 0x01, IRB1)
> 	    CreateByteField (B37A, 0x02, IRB2)
> 	    Name (B47A, ResourceTemplate ()
> 	    {
> 		Interrupt (ResourceConsumer, Level, ActiveLow, Shared)
> 		{
> 		    0x00000000,
> 		}
> 	    })
> 	    If (LNot (LEqual (DEID, 0x3177)))
> 	    {
> 		If (LNot (LEqual (DEID, 0x3147)))
> 		{
> 		    Return (B37A)
> 		}
> 		Else
> 		{
> 		    Return (B47A)
> 		}
> 	    }
> 	    Else
> 	    {
> 		Return (B47A)
> 	    }
> 
> 	    Store (0x00, Local3)
> 	    Store (0x00, Local4)
> 	    And (PIRA, 0xF0, Local1)
> 	    ShiftRight (Local1, 0x04, Local1)
> 	    If (LNot (LEqual (Local1, 0x00)))
> 	    {
> 		If (LGreater (Local1, 0x07))
> 		{
> 		    Subtract (Local1, 0x08, Local2)
> 		    ShiftLeft (One, Local2, Local4)
> 		}
> 		Else
> 		{
> 		    If (LGreater (Local1, 0x00))
> 		    {
> 			ShiftLeft (One, Local1, Local3)
> 		    }
> 		}
> 
> 		Store (Local3, IRB1)
> 		Store (Local4, IRB2)
> 	    }
> 	}
> 


-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en

RE: problems with PRT and PCI routing table

[Holger W.]

> None of this really helps you in the immediate term, sorry...

Never mind - it's nice to know that you're aware of the problem. Would be nice if the next
release (or at least another pre-final release) would contain a fix ;-)
Besides - compliment to all ACPI developers, you're doing a great job !

> Is this repeatable, if you compile it yourself from the acpica-unix
> package?

It seems that I've got a problem with my glibc packages. I'll update 'em and try again ...

Regards,

HOLGER W.



-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en