From owner-freebsd-acpi@FreeBSD.ORG Fri Oct 22 05:23:02 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 C875C106566B for ; Fri, 22 Oct 2010 05:23:02 +0000 (UTC) (envelope-from ming.m.lin@intel.com) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by mx1.freebsd.org (Postfix) with ESMTP id A2BEA8FC26 for ; Fri, 22 Oct 2010 05:23:02 +0000 (UTC) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga102.jf.intel.com with ESMTP; 21 Oct 2010 22:23:01 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.58,221,1286175600"; d="scan'208";a="669744473" Received: from minggr.sh.intel.com (HELO [10.239.13.26]) ([10.239.13.26]) by orsmga001.jf.intel.com with ESMTP; 21 Oct 2010 22:23:01 -0700 From: Lin Ming To: Hans Petter Selasky In-Reply-To: <1287715164.6530.3112.camel@minggr.sh.intel.com> References: <201010121209.06397.hselasky@c2i.net> <1287632360.6530.3103.camel@minggr.sh.intel.com> <1287645147.6530.3107.camel@minggr.sh.intel.com> <201010212257.58588.hselasky@c2i.net> <1287715164.6530.3112.camel@minggr.sh.intel.com> Content-Type: text/plain; charset="UTF-8" Date: Fri, 22 Oct 2010 13:19:47 +0800 Message-ID: <1287724787.6530.3135.camel@minggr.sh.intel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.30.2 Content-Transfer-Encoding: 7bit Cc: "freebsd-acpi@freebsd.org" , "Moore, Robert" 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, 22 Oct 2010 05:23:02 -0000 On Fri, 2010-10-22 at 10:39 +0800, Lin Ming wrote: > On Fri, 2010-10-22 at 04:57 +0800, Hans Petter Selasky wrote: > > Here is the relevant output. First note, the buffer length is 512 and > > (uint8_t)512 = 0, so I modified the code to print out the 512 bytes. > > > > > > Passed in resource buffer length=512 > > Buffer start > > 0f 00 00 00 40 00 00 00 01 00 01 01 01 17 01 00 38 b0 17 03 00 ff ff ff 11 00 > > 00 00 11 00 00 00 12 00 00 00 13 00 00 00 14 00 00 00 15 00 00 00 16 00 00 00 > > 17 00 00 0 > > 0 00 00 00 00 00 00 00 00 07 00 00 00 10 00 00 00 00 00 00 00 00 00 00 00 07 > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > 00 00 00 00 > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > 00 00 00 > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > 00 00 00 0 > > 0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > 00 00 00 00 > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > 00 00 00 > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > 00 00 00 0 > > 0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > 00 00 00 00 > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > 00 00 00 > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > Buffer end > > Unfortunately, I can't reproduce it in the simulator(acpiexec). Hans, This bug seems really strange. As above resource buffer you got, it's interpreted as below [00] Extended IRQ Resource Type : ResourceConsumer Triggering : Level Polarity : ActiveLow Sharing : Shared Resource Source Index : 17 Resource Source : [NULL NAMESTRING] Interrupt Count : 01 Dword00 : 00000011 [01] EndTag Resource [NULL NAMESTRING] actually means empty string with size 1 (1 byte for NULL terminator). You wrote: > It appears that when a string is present in the extended interrupt > descriptor (6.4.3.6, ACPIspec30.pdf), then this is not handled > correctly, meaning that the precomputed buffer space when encoding to > AML, is incorrect and that data is written beyond the destination > buffer! But for above resources, AcpiRsCreateAmlResources->AcpiRsGetAmlLength returns 13, which is the precomputed size for the AML buffer and it's correct. I'm lost now. Would you please try this patch to double check if the fault is really caused by the string in the extended interrupt descriptor? Tell us if it boots OK or not with this patch. Thanks. diff --git a/source/components/resources/rsxface.c b/source/components/resources/rsxface.c index 2a019d1..17b88e2 100644 --- a/source/components/resources/rsxface.c +++ b/source/components/resources/rsxface.c @@ -394,6 +394,7 @@ AcpiSetCurrentResources ( { ACPI_STATUS Status; ACPI_NAMESPACE_NODE *Node; + ACPI_RESOURCE *Res; ACPI_FUNCTION_TRACE (AcpiSetCurrentResources); @@ -416,6 +417,15 @@ AcpiSetCurrentResources ( return_ACPI_STATUS (Status); } + Res = (ACPI_RESOURCE *) InBuffer->Pointer; + if (Res->Type == ACPI_RESOURCE_TYPE_EXTENDED_IRQ) + { + /* DEBUG: clear the string to see if it's the root cause */ + + Res->Data.ExtendedIrq.ResourceSource.StringPtr = NULL; + Res->Data.ExtendedIrq.ResourceSource.StringLength = 0; + } + Status = AcpiRsSetSrsMethodData (Node, InBuffer); return_ACPI_STATUS (Status); }