Date: Fri, 29 Oct 2010 08:19:08 +0300 From: Andriy Gapon <avg@icyb.net.ua> To: Lin Ming <ming.m.lin@intel.com> Cc: freebsd-acpi@FreeBSD.org, "Moore, Robert" <robert.moore@intel.com>, Jung-uk Kim <jkim@FreeBSD.org> Subject: Re: MacBookPro 5,1 Message-ID: <4CCA594C.7050806@icyb.net.ua> In-Reply-To: <1288312476.13315.15.camel@minggr.sh.intel.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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?
--
Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4CCA594C.7050806>