panic: acpi_pci_link_srs_from_crs: can't put non-ISA IRQ 20 in legacy IRQ resource type)

[John Baldwin]

On Friday, April 19, 2013 06:21:10 PM Benjamin Lee wrote:
> On Fri, 19 Apr 2013 17:26:31 -0400, John Baldwin <jhb at freebsd.org> wrote:
> > On Friday, April 19, 2013 4:18:49 pm Benjamin Lee wrote:
> > > On Fri, 19 Apr 2013 11:31:49 -0400, John Baldwin <jhb at freebsd.org> 
wrote:
> > > > On Thursday, April 18, 2013 3:49:40 pm Benjamin Lee wrote:
> > > > > I have a system that panics on boot with 10-CURRENT and boots with
> > > > > many ACPI error messages and non-functional devices with
> > > > > 9.1-RELEASE.
> > > > > 
> > > > > Motherboard is Foxconn C51XEM2AA (NVIDIA nForce 590) desktop board.
> > > 
> > > [...]
> > > 
> > > > > Even though 9.1-RELEASE boots successfully, devices such as the
> > > > > ehci USB controller and SATA controller do not work.
> > > > 
> > > > Ugh, your BIOS does unexpected things.  It uses a _CRS for these pci
> > > > link devices that uses a "short" IRQ resource, but uses an extended
> > > > IRQ
> > 
> > resource in
> > 
> > > > _PRS (and expects an extended one in _SRS).  We use _CRS as a
> > > > template for
> > 
> > the
> > 
> > > > resource to build.
> > > > 
> > > > Try this patch.  It's a bit hackish, but it forces us to not use _CRS
> > > > as a template if _CRS uses a "short" IRQ resource, but the link
> > > > supports non-
> > 
> > ISA
> > 
> > > > IRQs.
> > > 
> > > [...]
> > > 
> > > Thanks, that fixed the panic and the system boots.  Now it is
> > > complaining about AE_AML_BAD_RESOURCE_LENGTH and still unable to route
> > > IRQs, but it definitely looks better than the ACPI parsing errors in 9:
> > > 
> > > pcib0: allocated type 3 (0xdffff000-0xdfffffff) for rid 10 of
> > > pci0:0:10:0 pcib0: matched entry for 0.10.INTA (src \_SB_.PCI0.AUBA:0)
> > > pci_link26: Picked IRQ 20 with weight 0
> > > pci_link26: Unable to route IRQs: AE_AML_BAD_RESOURCE_LENGTH
> > > 
> > > Full boot -v output:
> > > http://www.b1c1l1.com/media/debug/20130419-10-patched-
> > 
> > boot.txt.gz
> > 
> > Can you add some printfs to the places that return the
> > AE_AML_BAD_RESOURCE_LENGTH to see which one is being triggered?  (Just
> > look for that constant in sys/contrib/dev/acpica to find the possible
> > places.)
> 
> Is there a macro for dumping information about Resource or
> Resource->Data?  Here's what I have for now at
> sys/contrib/dev/acpica/resources/rscalc.c line 237:
> 
> pcib0: matched entry for 0.10.INTA (src \_SB_.PCI0.AUBA:0)
> pci_link26: Picked IRQ 20 with weight 0
> rscalc.c:237
> Resource->Type: 7
> Resource->Length: 0
> pci_link26: Unable to route IRQs: AE_AML_BAD_RESOURCE_LENGTH
> 
> All of the errors are from there and look identical (Type 7, Length 0).
> Type 7 appears to be ACPI_RESOURCE_TYPE_END_TAG.

Ah, this is easy to fix then.  It seems in sys/dev/acpica/acpi.c in 
acpi_AppendBufferResource() we didn't create the end tag correctly.
Can you try this in addition to the patch to acpi_pci_link.c:

Index: sys/dev/acpica/acpi.c
===================================================================
--- acpi.c	(revision 249195)
+++ acpi.c	(working copy)
@@ -2384,7 +2384,7 @@
     /* And add the terminator. */
     rp = ACPI_NEXT_RESOURCE(rp);
     rp->Type = ACPI_RESOURCE_TYPE_END_TAG;
-    rp->Length = 0;
+    rp->Length = ACPI_RS_SIZE_MIN;
 
     return (AE_OK);
 }


-- 
John Baldwin