Date: Fri, 19 Apr 2013 20:25:09 -0700 From: Benjamin Lee <ben@b1c1l1.com> To: "Moore, Robert" <robert.moore@intel.com> Cc: "freebsd-acpi@freebsd.org" <freebsd-acpi@freebsd.org>, "Guan, Chao" <chao.guan@intel.com>, "Zheng, Lv" <lv.zheng@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: <20130419202509.6a56d1d4@b1c1l1.com> In-Reply-To: <94F2FBAB4432B54E8AACC7DFDE6C92E36FE42EFF@FMSMSX153.amr.corp.intel.com> References: <20130418124940.47e3618a@b1c1l1.com> <201304191131.49433.jhb@freebsd.org> <20130419131849.7357c8f6@b1c1l1.com> <201304191726.31089.jhb@freebsd.org> <20130419152110.213c7fbb@b1c1l1.com> <20130419155118.7bafe9fc@b1c1l1.com> <94F2FBAB4432B54E8AACC7DFDE6C92E36FE42E28@FMSMSX153.amr.corp.intel.com> <20130419163528.204bf3ff@b1c1l1.com> <94F2FBAB4432B54E8AACC7DFDE6C92E36FE42EA2@FMSMSX153.amr.corp.intel.com> <20130419172200.45d8601b@b1c1l1.com> <94F2FBAB4432B54E8AACC7DFDE6C92E36FE42EFF@FMSMSX153.amr.corp.intel.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--Sig_/9_q.rxLcL.B0hrNKkw+kcXx
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
On Sat, 20 Apr 2013 01:44:42 +0000, "Moore, Robert" <robert.moore@intel.com=
> wrote:
> Disassembling the DSDT, we have this code in the _SRS execution path:
>=20
>=20
> Method (SRSA, 1, Serialized)
> {
> CreateWordField (Arg0, 0x05, INZ6)
>=20
>=20
> This code causes the main exception that was first reported:
>=20
> ACPI Error: Field [INZ6] at 56 exceeds Buffer [NULL] size 48 (bits) (2013=
0418/dsopcode-326)
> [AcpiExec] Exception AE_AML_BUFFER_LIMIT during execution of method [SRSA=
] Opcode [CreateWordField] @4
>=20
>=20
> This code should not be a WORD field, it needs to be a BYTE field. This i=
s because the incoming buffer (Arg0) is exactly 6 bytes long -- so a WORD f=
ield at offset 5 will overrun the buffer.
>=20
> It looks like the code is attempting to access the last byte of the resou=
rce descriptor, which is the second byte of the EndTag.
>=20
>=20
>=20
>=20
> Here is the fixed code:
>=20
> Method (SRSA, 1, Serialized)
> {
> CreateByteField (Arg0, 0x05, INZ6)
>=20
>=20
>=20
>=20
> Recompiling the DSDT and executing resource command, there are no errors:
[...]
> So, this is obviously a rather serious bug in the DSDT that will need to =
be addressed by the vendor. Chances are, there are a few more issues like t=
his in the code.
>=20
> As far as workarounds -- I'm sorry, but we can't allow a buffer overrun, =
and we can't "guess" what the code is really attempting to do. The correct =
execution is an abort with the exception AE_AML_BUFFER_LIMIT.
>=20
> I don't see any issues with the resource lengths, but I will double-check.
Thank you! I have modified my ASL to use CreateByteField in the SRSA
method.
Unfortunately, I'm now seeing the following:
With 9.1-RELEASE, all ACPI errors are gone but devices still do not work
(even though they appear to be getting the proper PCI IRQs now instead
of ISA IRQs). Nothing is complaining about AE_AML_BAD_RESOURCE_LENGTH,
which confirms your observation that resource lengths in the ASL seem to
be OK.
10-CURRENT is still triggering my ACPI_RESOURCE_TYPE_END_TAG hack (and
devices are functioning), which might indicate a regression related to
resource lengths.
9.1-RELEASE (fixed ASL) boot -v: http://www.b1c1l1.com/media/debug/20130419=
-fixedasl-9-boot.txt.gz
10-CURRENT (fixed ASL) boot -v: http://www.b1c1l1.com/media/debug/20130419-=
fixedasl-10-patched-boot.txt.gz
In comparing the outputs, I see that 9.1-RELEASE prints 3 INTR messages:
INTR: Adding local APIC 0 as a target
INTR: Adding local APIC 0 as a target
INTR: Adding local APIC 1 as a target
while in 10-CURRENT I only see 1 INTR message:
INTR: Adding local APIC 1 as a target
which might be related to devices not working since they are being
routed to lapic 0.
> Bob
>=20
>=20
>=20
>=20
>=20
> > -----Original Message-----
> > From: Moore, Robert
> > Sent: Friday, April 19, 2013 5:52 PM
> > To: 'Benjamin Lee'
> > 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)
> >=20
> > I was able to quickly reproduce the _CRS/_SRS problem with the AUBA
> > device. I would imagine that this would fail on Windows also, as the ba=
sic
> > model of read(_CRS)/modify/write(_SRS) is fairly standard. Unless
> > something else is going on, of course.
> >=20
> > Our debugger has a command to do this:
> >=20
> >=20
> > - resource \_SB_.PCI0.AUBA
> >=20
> > Device: \_SB_.PCI0.AUBA
> > Evaluating _CRS
> > rscalc-0663 [04] RsGetListLength : Type 20, AmlLength 04
> > InternalLength 10
> > rslist-0217 [05] RsConvertAmlToResource: Type 20, AmlLength 04
> > InternalLength 10
> > rslist-0217 [05] RsConvertAmlToResource: Type 78, AmlLength 02
> > InternalLength 0C
> > rscalc-0663 [04] RsGetListLength : Type 20, AmlLength 04
> > InternalLength 10
> > rslist-0217 [05] RsConvertAmlToResource: Type 20, AmlLength 04
> > InternalLength 10
> > rslist-0217 [05] RsConvertAmlToResource: Type 78, AmlLength 02
> > InternalLength 0C
> >=20
> > [00] IRQ Resource
> > Descriptor Length : 03
> > Triggering : Level
> > Polarity : ActiveLow
> > Sharing : Shared
> > Interrupt Count : 00
> > Interrupt List :
> >=20
> > [01] EndTag Resource
> > Resource Conversion Comparison:
> > rscalc-0663 [04] RsGetListLength : Type 20, AmlLength 04
> > InternalLength 10
> > rslist-0217 [05] RsConvertAmlToResource: Type 20, AmlLength 04
> > InternalLength 10
> > rslist-0217 [05] RsConvertAmlToResource: Type 78, AmlLength 02
> > InternalLength 0C Evaluating _SRS ACPI Error: Field [INZ6] at 56 exceeds
> > Buffer [NULL] size 48 (bits) (20130418/dsopcode-326) [AcpiExec] Excepti=
on
> > AE_AML_BUFFER_LIMIT during execution of method [SRSA] Opcode
> > [CreateWordField] @4
> >=20
> > **** Exception AE_AML_BUFFER_LIMIT during execution of method
> > [\_SB_.PCI0.SRSA] (Node 004B7B50)
> >=20
> > Method Execution Stack:
> > Method [SRSA] executing: [SRSA] @00000 #008B: CreateWordField (Arg=
0,
> > 0x05, INZ6)
> > Method [_SRS] executing: Call to method [\_SB_.PCI0.SRSA] (Node
> > 004B7B50)
> >=20
> > Local Variables for method [SRSA]:
> > Local0: 00000000 <Null Object>
> > Local1: 00000000 <Null Object>
> > Local2: 00000000 <Null Object>
> > Local3: 00000000 <Null Object>
> > Local4: 00000000 <Null Object>
> > Local5: 00000000 <Null Object>
> > Local6: 00000000 <Null Object>
> > Local7: 00000000 <Null Object>
> >=20
> > Arguments for Method [SRSA]: (1 arguments defined, max concurrency =3D=
0)
> > Arg0: 004F4840 <Obj> Buffer(6) 23 00 00 18 79 00
> > Arg1: 00000000 <Null Object>
> > Arg2: 00000000 <Null Object>
> > Arg3: 00000000 <Null Object>
> > Arg4: 00000000 <Null Object>
> > Arg5: 00000000 <Null Object>
> > Arg6: 00000000 <Null Object>
> >=20
> > ACPI Error: Method parse/execution failed [\_SB_.PCI0.SRSA] (Node
> > 004B7B50), AE_AML_BUFFER_LIMIT (20130418/psparse-632) ACPI Error: Method
> > parse/execution failed [\_SB_.PCI0.AUBA._SRS] (Node 004BEB50),
> > AE_AML_BUFFER_LIMIT (20130418/psparse-632) AcpiSetCurrentResources fail=
ed:
> > AE_AML_BUFFER_LIMIT Evaluating _PRS
> > rscalc-0663 [04] RsGetListLength : Type 89, AmlLength 15
> > InternalLength 28
> > rslist-0217 [05] RsConvertAmlToResource: Type 89, AmlLength 15
> > InternalLength 28
> > rslist-0217 [05] RsConvertAmlToResource: Type 78, AmlLength 02
> > InternalLength 0C
> >=20
> > [00] Extended IRQ Resource
> > Type : ResourceConsumer
> > Triggering : Level
> > Polarity : ActiveLow
> > Sharing : Shared
> > Resource Source Index : 00
> > Resource Source : [Not Specified]
> > Interrupt Count : 04
> > Dword00 : 00000014
> > Dword01 : 00000015
> > Dword02 : 00000016
> > Dword03 : 00000017
> >=20
> > [01] EndTag Resource
> > -
> >=20
> >=20
> >=20
> > > -----Original Message-----
> > > From: Benjamin Lee [mailto:ben@b1c1l1.com]
> > > Sent: Friday, April 19, 2013 5:22 PM
> > > To: Moore, Robert
> > > Cc: John Baldwin; freebsd-acpi@freebsd.org
> > > Subject: Re: panic: acpi_pci_link_srs_from_crs: can't put non-ISA IRQ
> > > 20 in legacy IRQ resource type)
> > >
> > > On Sat, 20 Apr 2013 00:09:55 +0000, "Moore, Robert"
> > > <robert.moore@intel.com> wrote:
> > > > Can you send the actual binary DSDT or the ASCII acpidump (not
> > > > disassembled)
> > >
> > > I missed this earlier, but I just noticed _OS and _OSI checks for
> > Windows.
> > > I'll need to do some testing with hw.acpi.osname.
> > >
> > > Here is the binary DSDT:
> > >
> > > http://www.b1c1l1.com/media/debug/20130419-nvidia.dsdt
> > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Benjamin Lee [mailto:ben@b1c1l1.com]
> > > > > Sent: Friday, April 19, 2013 4:35 PM
> > > > > To: Moore, Robert
> > > > > Cc: John Baldwin; freebsd-acpi@freebsd.org
> > > > > Subject: Re: panic: acpi_pci_link_srs_from_crs: can't put non-ISA
> > > > > IRQ 20 in legacy IRQ resource type)
> > > > >
> > > > > On Fri, 19 Apr 2013 23:00:07 +0000, "Moore, Robert"
> > > > > <robert.moore@intel.com> wrote:
> > > > > > No, the length must be set in all descriptors, end tag included.
> > > > >
> > > > > Do you have any pointers on how I can fix my ASL? Where do I find
> > > > > the end tags and what should I set the lengths to?
> > > > >
> > > > > Here is the output from acpidump -dt:
> > > > > http://www.b1c1l1.com/media/debug/20130418-nvidia.asl.gz
> > > > >
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: owner-freebsd-acpi@freebsd.org [mailto:owner-freebsd-
> > > > > > > acpi@freebsd.org] On Behalf Of Benjamin Lee
> > > > > > > Sent: Friday, April 19, 2013 3:51 PM
> > > > > > > To: John Baldwin
> > > > > > > Cc: freebsd-acpi@freebsd.org
> > > > > > > Subject: Re: panic: acpi_pci_link_srs_from_crs: can't put
> > > > > > > non-ISA IRQ 20 in legacy IRQ resource type)
> > > > > > >
> > > > > > > On Fri, 19 Apr 2013 15:21:10 -0700, Benjamin Lee
> > > > > > > <ben@b1c1l1.com>
> > > > > wrote:
> > > > > > > > On Fri, 19 Apr 2013 17:26:31 -0400, John Baldwin
> > > > > > > > <jhb@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@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.
> > > > > > >
> > > > > > > This hack fixes everything (now the SATA controller works).
> > > > > > > It seems that the Resource->Length check might not be
> > > > > > > necessary for ACPI_RESOURCE_TYPE_END_TAG.
> > > > > > >
> > > > > > > blee@genesis /usr/src/sys/contrib/dev/acpica $ svn diff
> > > > > > > Index: components/resources/rscalc.c
> > > > > > >
> > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > > > > > > --- components/resources/rscalc.c (revision 249624)
> > > > > > > +++ components/resources/rscalc.c (working copy)
> > > > > > > @@ -234,6 +234,15 @@
> > > > > > >
> > > > > > > if (!Resource->Length)
> > > > > > > {
> > > > > > > + if (Resource->Type =3D=3D ACPI_RESOURCE_TYPE_END=
_TAG) {
> > > > > > > + TotalSize =3D AcpiGbl_AmlResourceSizes
> > > > > > > + [Resource-
> > > > > >Type];
> > > > > > > + printf("TotalSize: %u\n", TotalSize);
> > > > > > > + if (TotalSize !=3D 0) {
> > > > > > > + printf("ACPI_RESOURCE_TYPE_END_TAG
> > hack\n");
> > > > > > > + *SizeNeeded =3D AmlSizeNeeded + TotalSiz=
e;
> > > > > > > + return_ACPI_STATUS (AE_OK);
> > > > > > > + }
> > > > > > > + }
> > > > > > > return_ACPI_STATUS (AE_AML_BAD_RESOURCE_LENGTH);
> > > > > > > }
> > > > > > >
> > > > > > > Index: components/resources/rslist.c
> > > > > > >
> > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > > > > > > --- components/resources/rslist.c (revision 249624)
> > > > > > > +++ components/resources/rslist.c (working copy)
> > > > > > > @@ -203,6 +203,11 @@
> > > > > > >
> > > > > > > if (!Resource->Length)
> > > > > > > {
> > > > > > > + if (Resource->Type =3D=3D ACPI_RESOURCE_TYPE_END=
_TAG) {
> > > > > > > + printf("ACPI_RESOURCE_TYPE_END_TAG hack 2\n"=
);
> > > > > > > + return_ACPI_STATUS (AE_OK);
> > > > > > > + }
> > > > > > > +
> > > > > > > ACPI_ERROR ((AE_INFO,
> > > > > > > "Invalid zero length descriptor in resource
> > > > > list\n"));
> > > > > > > return_ACPI_STATUS (AE_AML_BAD_RESOURCE_LENGTH);
--=20
Benjamin Lee
http://www.b1c1l1.com/
--Sig_/9_q.rxLcL.B0hrNKkw+kcXx
Content-Type: application/pgp-signature; name=signature.asc
Content-Disposition: attachment; filename=signature.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iQIcBAEBAgAGBQJRcgqhAAoJEHpz6H1iC6qDGcsP/2IhjQRic4t+hZ1FiFUWckQS
4Gcv18cOmSbr1W0hmSublcJ4deGgUkCpT6jH7hDmw+E0cpeACguQ//a7w4jepbDt
808/gPeeDRfiHY+Iu1+4NXKudS7ad3F05pS+OvKzTnfE2Aya5wP7pwuOsmp6hiZ2
PSY9W1AOb4P/rbJJFuwsuAnZSL2vxgXicm8+eC2tPlotkuw6xAsFZ953F+QVwPMJ
0c236jx43dR+v5u0qKh011K0iCz3RR9aPQUitUol38sd/QroSCIcP/JRQzTQLMgg
hlXFLgbxqyGnqey2mz6HvcJUcQ/Pj5N6o3jjXCPqEEdN2O51XOE4ponjoM9zGe1u
zw5fQ2Qf1WHn79qQbizTp9eKO/tpr9XWO+ec+X2WvLBGZ4rYCOupaEiSJZAjY/GK
lyAqqNaMPpv3amPMnA8vGIG+IuzCm8esI1OJc8oJUuaJ7J1pwpvXEWV2JjNntB/W
xR/NIY4wn3aLv3tf9CmMsvUDRPae1LJr6253nSUkfFHFT8DddmjthxtE8+be0CkN
rRRY+5M+g+bNmQdMpRTnHIscJynclpkPuZH+m/jsfScO5X2wo7KVRj7/0Yza9qwm
qcNLdVk5JZSEvocOB+SI8BIydISDZn+Ba82MJJEgF81m/mW1hCJ9qO4Q4wLIX1O6
tLDCyhgvTORugXQtc3ye
=lf6i
-----END PGP SIGNATURE-----
--Sig_/9_q.rxLcL.B0hrNKkw+kcXx--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130419202509.6a56d1d4>