From owner-freebsd-acpi@FreeBSD.ORG Thu May 29 13:51:08 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 36D8230F; Thu, 29 May 2014 13:51:08 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 10B482BCE; Thu, 29 May 2014 13:51:08 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 0E18AB9CC; Thu, 29 May 2014 09:51:07 -0400 (EDT) From: John Baldwin To: "Jung-uk Kim" Subject: Re: Investigating failed suspend/resume T61 Date: Thu, 29 May 2014 09:25:22 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: <1400861698.1126.0.camel@bruno> <201405281729.35703.jhb@freebsd.org> <53865FCA.6080407@FreeBSD.org> In-Reply-To: <53865FCA.6080407@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201405290925.22969.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 29 May 2014 09:51:07 -0400 (EDT) Cc: "freebsd-acpi@freebsd.org" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 13:51:08 -0000 On Wednesday, May 28, 2014 6:14:34 pm Jung-uk Kim wrote: > On 2014-05-28 17:29:35 -0400, John Baldwin wrote: > > Err, I think it enables GPE1 as otherwise ACPICA assumes GPE1 has a > > length of zero (and is thus invalid)? Perhaps _PTS wants to frob > > something that uses GPE1 that this fixes? > > static void > AcpiTbValidateFadt ( > void) > { > ... > UINT8 Length; > ... > for (i = 0; i < ACPI_FADT_INFO_ENTRIES; i++) > { > ... > Length = *ACPI_ADD_PTR (UINT8, > &AcpiGbl_FADT, FadtInfoTable[i].Length); > ... > > Note the Length is read from the internal FADT and it is NOT a pointer. > > ... > if (Address64->Address && > (ACPI_MUL_8 (Length) <= ACPI_UINT8_MAX) && > (Address64->BitWidth != ACPI_MUL_8 (Length))) > { > ACPI_BIOS_WARNING ((AE_INFO, > "32/64X length mismatch in FADT/%s: %u/%u", > Name, ACPI_MUL_8 (Length), Address64->BitWidth)); > + if (Length == 0) > + { > + Length = ACPI_DIV_8 (Address64->BitWidth); > + } > } > ... > } > } > > AFAICT, it does change anything in AcpiGbl_FADT. If you really wanted > to "patch" it, you had to do something like this: > > + if (Length == 0) > + { > + Length = ACPI_DIV_8 (Address64->BitWidth); > + *ACPI_ADD_PTR (UINT8, > + &AcpiGbl_FADT, FadtInfoTable[i].Length) = Length; > + } > > However, it had to be done from AcpiEvGpeInitialize() in > sys/contrib/dev/acpica/components/events/evgpeinit.c, IMHO. > > ACPI_STATUS > AcpiEvGpeInitialize ( > void) > { > ... > if (AcpiGbl_FADT.Gpe1BlockLength && > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > HERE!!! > AcpiGbl_FADT.XGpe1Block.Address) > { > ... > > What did I miss? Nothing, I've no idea how this could possibly have affected suspend/resume on Sean's laptop then. Maybe it was just a coincidence. -- John Baldwin