From owner-freebsd-acpi@FreeBSD.ORG Fri Oct 29 05:19:20 2010 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 091CC1065670; Fri, 29 Oct 2010 05:19:20 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 0C1508FC14; Fri, 29 Oct 2010 05:19:18 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id IAA27789; Fri, 29 Oct 2010 08:19:10 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1PBhMr-000DjE-Nb; Fri, 29 Oct 2010 08:19:09 +0300 Message-ID: <4CCA594C.7050806@icyb.net.ua> Date: Fri, 29 Oct 2010 08:19:08 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.11) Gecko/20101021 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: Lin Ming 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> In-Reply-To: <1288312476.13315.15.camel@minggr.sh.intel.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org, "Moore, Robert" , Jung-uk Kim Subject: Re: MacBookPro 5,1 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 05:19:20 -0000 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