MacBookPro 5,1

[Andriy Gapon]

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