Date: Mon, 29 Apr 2013 11:59:40 -0400 From: John Baldwin <jhb@freebsd.org> To: "Moore, Robert" <robert.moore@intel.com> Cc: "freebsd-acpi@freebsd.org" <freebsd-acpi@freebsd.org>, "Zheng, Lv" <lv.zheng@intel.com>, "Guan, Chao" <chao.guan@intel.com> Subject: Re: panic: acpi_pci_link_srs_from_crs: can't put non-ISA IRQ 20 in legacy IRQ resource type) Message-ID: <201304291159.40609.jhb@freebsd.org> In-Reply-To: <94F2FBAB4432B54E8AACC7DFDE6C92E36FE44F8D@FMSMSX153.amr.corp.intel.com> References: <20130418124940.47e3618a@b1c1l1.com> <20130426113948.10b5400e@b1c1l1.com> <94F2FBAB4432B54E8AACC7DFDE6C92E36FE44F8D@FMSMSX153.amr.corp.intel.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday, April 26, 2013 2:59:20 pm Moore, Robert wrote:
>
> > -----Original Message-----
> > From: Benjamin Lee [mailto:ben@b1c1l1.com]
> > Sent: Friday, April 26, 2013 11:40 AM
> > To: Moore, Robert
> > Cc: John Baldwin; freebsd-acpi@freebsd.org; Zheng, Lv; Guan, Chao
> > Subject: Re: panic: acpi_pci_link_srs_from_crs: can't put non-ISA IRQ 20
> > in legacy IRQ resource type)
> >
> > On Thu, 25 Apr 2013 02:28:25 +0000, "Moore, Robert"
> > <robert.moore@intel.com> wrote:
> > > > Thank you! I backed out my hacks and with your 2 patches 10-CURRENT
> > > > boots successfully (with functional devices). Loading a custom ASL
> > > > is not necessary.
> > >
> > > Do you mean that the change of a WORD field to a BYTE field is no longer
> > necessary?
> > >
> > > If so, I would really like to see the buffer that is being sent to _SRS.
> >
> > Yes, the change of WORD to BYTE is not necessary with 10-CURRENT.
> >
> > I don't understand ACPI well enough to answer your followup. All I know
> > is that there is some change in the ACPI parsing behavior between 9-STABLE
> > (which triggers AE_AML_BUFFER_LIMIT in the broken _SRS method) and 10-
> > CURRENT (which used to panic but after jhb's fixes now boots correctly).
> > Could it be possible that _SRS is not being called at all with the new
> > ACPI code?
> >
>
>
> _SRS is called from the driver software, so ACPICA is not involved. It may
be that the resource descriptor is now a little longer and the WORD access no
longer goes beyond the end of the buffer.
>
> Still, I'm a bit worried about it anyway.
_SRS is expecting an ExtendedIRQ resource (hence why it is accessing a word
field as in an ExtendedIRQ resource the IRQ is a word at that offset). This
is consistent with what _PRS returns for these links. It is only _CRS that is
using a non-Extended IRQ resource for these link devices. I can give Benjamin
a patch to add a call to AcpiRsDumpResourceList() before calling
AcpiSetCurrentResources() if you'd like to see the output of that. Something
like this I think:
Index: acpi_pci_link.c
===================================================================
--- acpi_pci_link.c (revision 249767)
+++ acpi_pci_link.c (working copy)
@@ -866,6 +866,8 @@
status = acpi_pci_link_srs_from_crs(sc, &srsbuf);
/* Write out new resources via _SRS. */
+ device_printf(dev, "Resource list:\n");
+ AcpiRsDumpResourceList(srsbuf.Pointer);
status = AcpiSetCurrentResources(acpi_get_handle(dev), &srsbuf);
if (ACPI_FAILURE(status)) {
device_printf(dev, "Unable to route IRQs: %s\n",
--
John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201304291159.40609.jhb>