From owner-freebsd-acpi@FreeBSD.ORG Mon Apr 29 16:13:38 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 42F40B38 for ; Mon, 29 Apr 2013 16:13:38 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) by mx1.freebsd.org (Postfix) with ESMTP id 1E2CA1E42 for ; Mon, 29 Apr 2013 16:13:38 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 81892B990; Mon, 29 Apr 2013 12:13:37 -0400 (EDT) From: John Baldwin To: "Moore, Robert" Subject: Re: panic: acpi_pci_link_srs_from_crs: can't put non-ISA IRQ 20 in legacy IRQ resource type) Date: Mon, 29 Apr 2013 11:59:40 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <20130418124940.47e3618a@b1c1l1.com> <20130426113948.10b5400e@b1c1l1.com> <94F2FBAB4432B54E8AACC7DFDE6C92E36FE44F8D@FMSMSX153.amr.corp.intel.com> In-Reply-To: <94F2FBAB4432B54E8AACC7DFDE6C92E36FE44F8D@FMSMSX153.amr.corp.intel.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201304291159.40609.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 29 Apr 2013 12:13:37 -0400 (EDT) Cc: "freebsd-acpi@freebsd.org" , "Zheng, Lv" , "Guan, Chao" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 16:13:38 -0000 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" > > 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