Date: Fri, 29 Oct 2010 08:23:07 +0300 From: Andriy Gapon <avg@icyb.net.ua> To: Lin Ming <ming.m.lin@intel.com>, Hans Petter Selasky <hselasky@c2i.net> Cc: freebsd-acpi@FreeBSD.org, "Moore, Robert" <robert.moore@intel.com>, Jung-uk Kim <jkim@FreeBSD.org> Subject: Re: MacBookPro 5,1 Message-ID: <4CCA5A3B.9000101@icyb.net.ua> In-Reply-To: <4CCA594C.7050806@icyb.net.ua> References: <201010121209.06397.hselasky@c2i.net> <1288278300.2459.19.camel@localhost> <1288279472.2459.22.camel@localhost> <201010281810.23668.hselasky@c2i.net> <1288312476.13315.15.camel@minggr.sh.intel.com> <4CCA594C.7050806@icyb.net.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
on 29/10/2010 08:19 Andriy Gapon said the following:
> on 29/10/2010 03:34 Lin Ming said the following:
>> Hi, guys
>>
>> Hans and I have found the root cause of this bug.
>
> I believe that there could be a root for a root :-)
>
>> The ResourceSource->StringLength set by up layer driver is wrong, see the patch below.
>>
>> Below patch fixes the bug and on Hans' machine it prints,
>>
>> Bug: the passed in resource buffer is wrong, Resource->StringLength=1, but the real string length is 10
>> Bug: the passed in resource buffer is wrong, Resource->StringLength=1, but the real string length is 10
>> Bug: the passed in resource buffer is wrong, Resource->StringLength=1, but the real string length is 10
>> Bug: the passed in resource buffer is wrong, Resource->StringLength=1, but the real string length is 8
>> Bug: the passed in resource buffer is wrong, Resource->StringLength=1, but the real string length is 10
>> Bug: the passed in resource buffer is wrong, Resource->StringLength=1, but the real string length is 10
>> Bug: the passed in resource buffer is wrong, Resource->StringLength=1, but the real string length is 10
>> Bug: the passed in resource buffer is wrong, Resource->StringLength=1, but the real string length is 10
>> Bug: the passed in resource buffer is wrong, Resource->StringLength=1, but the real string length is 10
>>
>> The full dmesg also attached.
>>
>> Kim,
>>
>> Could you write a fix in up layer code(seems in acpi_pci_link_route_irqs)?
>>
>> Thanks.
>>
>> diff --git a/source/components/resources/rscalc.c b/source/components/resources/rscalc.c
>> index 3215c9e..e68b5af 100644
>> --- a/source/components/resources/rscalc.c
>> +++ b/source/components/resources/rscalc.c
>> @@ -203,7 +203,13 @@ AcpiRsStructOptionLength (
>> */
>> if (ResourceSource->StringPtr)
>> {
>> - return ((ACPI_RS_LENGTH) (ResourceSource->StringLength + 1));
>> + if (ACPI_STRLEN (ResourceSource->StringPtr) + 1 != ResourceSource->StringLength)
>> + {
>> + AcpiOsPrintf("Bug: the passed in resource buffer is wrong, ResourceSource->StringLength=%d, "
>> + "but the real string length is %d\n",
>> + ResourceSource->StringLength, ACPI_STRLEN (ResourceSource->StringPtr) + 1);
>> + }
>> + return ((ACPI_RS_LENGTH) ((ACPI_STRLEN (ResourceSource->StringPtr) + 1) + 1));
>> }
>>
>> return (0);
>>
>
> As Hans has reported previously, it seems that resources for _SRS are prepared
> by acpi_pci_link_srs_from_crs() in his case.
> acpi_pci_link_srs_from_crs is a sufficiently small function that doesn't seem to
> manipulate strings in any resources:
> http://fxr.watson.org/fxr/source/dev/acpica/acpi_pci_link.c#L689
>
> At this line
> http://fxr.watson.org/fxr/source/dev/acpica/acpi_pci_link.c#L746
> you can see that a resource is assigned from l_prs_template.
>
> l_prs_template is populated in link_add_prs() function, which called to walk
> over resources returned by _PRS:
> http://fxr.watson.org/fxr/source/dev/acpica/acpi_pci_link.c#L499
> http://fxr.watson.org/fxr/source/dev/acpica/acpi_pci_link.c#L269
> http://fxr.watson.org/fxr/source/dev/acpica/acpi_pci_link.c#L324
>
> So, it would seem that those incorrect lengths would come from evaluation of
> _PRS by ACPICA code. But that's probably a naive conclusion, it could be that
> we incorrectly manipulate a received resource.
>
> It seems that the source of the trouble is resource template in BUFF, judging
> from e.g. _PRS for LNK1 (in DSDT dump that Hans has provided).
>
> I guess that we probably need more help with tracking this down further.
> Could it be that we get or somehow insert/copy garbage as a content of a string
> that should be empty?
Now that I wrote this, could the bug be in the following FreeBSD function:
http://fxr.watson.org/fxr/source/dev/acpica/acpi.c?im=10#L2150
I guess Hans could insert the same code for verifying string length in the
strategic places mentioned above to catch the exact place where string length
and string content get out of sync.
--
Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4CCA5A3B.9000101>