From owner-freebsd-acpi@FreeBSD.ORG Wed May 28 21:30:01 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 74D98481; Wed, 28 May 2014 21:30:01 +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 48B2B276F; Wed, 28 May 2014 21:30:01 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 86437B939; Wed, 28 May 2014 17:29:59 -0400 (EDT) From: John Baldwin To: "Jung-uk Kim" Subject: Re: Investigating failed suspend/resume T61 Date: Wed, 28 May 2014 17:29:35 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: <1400861698.1126.0.camel@bruno> <201405281556.37651.jhb@freebsd.org> <538641DE.5030309@FreeBSD.org> In-Reply-To: <538641DE.5030309@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201405281729.35703.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 28 May 2014 17:29:59 -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: Wed, 28 May 2014 21:30:01 -0000 On Wednesday, May 28, 2014 4:06:54 pm Jung-uk Kim wrote: > On 2014-05-28 15:56:37 -0400, John Baldwin wrote: > > On Wednesday, May 28, 2014 2:16:03 pm Jung-uk Kim wrote: > >> On 2014-05-28 13:44:46 -0400, John Baldwin wrote: > >>> On Wednesday, May 28, 2014 12:44:44 pm Jung-uk Kim wrote: > >>>> On 2014-05-28 12:20:24 -0400, John Baldwin wrote: > >>>>> On Wednesday, May 28, 2014 12:10:55 pm Sean Bruno wrote: > >>>>>> On Wed, 2014-05-28 at 10:54 -0400, John Baldwin wrote: > >>>>>>> On Wednesday, May 28, 2014 7:08:36 am Sean Bruno > >>>>>>> wrote: > >>>>>>>> On Tue, 2014-05-27 at 16:14 -0400, John Baldwin > >>>>>>>> wrote: > >>>>>>>>> On Tuesday, May 27, 2014 1:39:48 pm Sean Bruno > >>>>>>>>> wrote: > >>>>>>>>>> On Tue, 2014-05-27 at 11:32 -0400, John Baldwin > >>>>>>>>>> wrote: > >>>>>>>>>>> On Friday, May 23, 2014 12:14:58 pm Sean Bruno > >>>>>>>>>>> wrote: > >>>>>>>>>>>> Trying to figure out the failures on suspend > >>>>>>>>>>>> resume for the T61 I have. I see a little > >>>>>>>>>>>> acpi error at host startup, but I don't think > >>>>>>>>>>>> its related. However, I'm not sure what it > >>>>>>>>>>>> means. > >>>>>>>>>>>> > >>>>>>>>>>>> sean > >>>>>>>>>>>> > >>>>>>>>>>>> ------ > >>>>>>>>>>>> > >>>>>>>>>>>> FreeBSD 11.0-CURRENT #1 r265820: Sat May 10 > >>>>>>>>>>>> 15:13:37 PDT 2014 > >>>>>>>>>>>> sbruno@bruno:/usr/obj/usr/src/sys/BRUNO > >>>>>>>>>>>> amd64 FreeBSD clang version 3.4 > >>>>>>>>>>>> (tags/RELEASE_34/final 197956) 20140216 VT: > >>>>>>>>>>>> running with driver "vga". CPU: Intel(R) > >>>>>>>>>>>> Core(TM)2 Duo CPU T7300 @ 2.00GHz > >>>>>>>>>>>> (1995.04-MHz K8-class CPU) > >>>>>>>>>>>> Origin="GenuineIntel" Id=0x6fa Family=0x6 > >>>>>>>>>>>> Model=0xf Stepping=10 > >>>>>>>>>>>> > >>>>>>>>>>>> > >>> > > Features=0xbfebfbff > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>> > >>> > >> > > > Features2=0xe3bd > >>>>>>>>>>>> AMD Features=0x20100800 AMD > >>>>>>>>>>>> Features2=0x1 TSC: P-state invariant, > >>>>>>>>>>>> performance statistics real memory = > >>>>>>>>>>>> 2147483648 (2048 MB) avail memory = > >>>>>>>>>>>> 2007138304 (1914 MB) Event timer "LAPIC" > >>>>>>>>>>>> quality 400 ACPI APIC Table: >>>>>>>>>>>> > FreeBSD/SMP: Multiprocessor System > >>>>>>>>>>>> Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x > >>>>>>>>>>>> 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): > >>>>>>>>>>>> APIC ID: 1 ACPI BIOS Warning (bug): 32/64X > >>>>>>>>>>>> length mismatch in FADT/Gpe1Block: 0/32 > >>>>>>>>>>>> (20130823/tbfadt-601) ACPI BIOS Warning > >>>>>>>>>>>> (bug): Optional FADT field Gpe1Block has zero > >>>>>>>>>>>> address or length: 0x000000000000102C/0x0 > >>>>>>>>>>>> (20130823/tbfadt-630) > >>>>>>>>>>> > >>>>>>>>>>> It might be related as Gpe1Block describes a > >>>>>>>>>>> register set that IIRC is used to enter sleep > >>>>>>>>>>> states. Can you put your acpidump -t > >>>>>>>>>>> somewhere? (No need for -d as this is in the > >>>>>>>>>>> FADT, not the DSDT.) > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Here --> > >>>>>>>>>> http://people.freebsd.org/~sbruno/T61_acpidump.txt > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> > Ah, so the warning is due to the fact that the 'FACP' > >>>>>>>>> table has 'X_GPE1_BLOCK' but no 'GPE1_BLOCK'. > >>>>>>>>> (Note how it has both 'GPE0_BLOCK' and > >>>>>>>>> 'X_GPE0_BLOCK' which say the same thing.) Try this > >>>>>>>>> workaround to quiet the warning. I've no idea if > >>>>>>>>> it will help at all with suspend/resume. > >>>>>>>>> > >>>>>>>>> Index: > >>>>>>>>> sys/contrib/dev/acpica/components/tables/tbfadt.c > >>>>>>>>> =================================================================== > >>>>>>>>> > >>>>>>>>> > >>>> > >>>>>>>>> > >> > >>>>>>>>> > --- tbfadt.c (revision 266442) > >>>>>>>>> +++ tbfadt.c (working copy) @@ -601,6 +601,10 @@ > >>>>>>>>> AcpiTbValidateFadt ( 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); + } } > >>>>>>>>> > >>>>>>>>> if (FadtInfoTable[i].Type & ACPI_FADT_REQUIRED) > >>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>>> One warning went away, one remains, not sure if its > >>>>>>>> meaningful or not. > >>>>>>>> > >>>>>>>> ACPI BIOS Warning (bug): 32/64X length mismatch in > >>>>>>>> FADT/Gpe1Block: 0/32 (20130823/tbfadt-601) > >>>>>>> > >>>>>>> Yes, I didn't remove that warning, I just fixed it to > >>>>>>> use the 64-bit length when the 32-bit length was zero > >>>>>>> when that warning fires. Does this seem to have made > >>>>>>> any difference with anything on the laptop? (E.g. it > >>>>>>> might possibly affect hotkeys, etc.) > >>>>>>> > >>>>>> > >>>>>> > >>>>>> Believe it or not, but I just suspend/resumed on the > >>>>>> thing, TWICE. Once from the xfce menu -> suspend and > >>>>>> once from Fn->moonsymbolsuspendsleepthing on the F4 key. > >>>>>> > >>>>>> Good grief. Thanks John. > >>>>> > >>>>> Humm. I wonder if we can get the Intel guys to accept the > >>>>> patch upstream? > >>>> > >>>> Yes, ACPICA guys are very open to patches. Actually there > >>>> are several ways to report bugs and/or submit patches. > >>>> > >>>> Bug reports: https://bugs.acpica.org > >>>> > >>>> Developer ML: > >>>> https://lists.acpica.org/mailman/listinfo/devel > >>>> > >>>> Source repository: https://github.com/acpica/acpica > >>>> > >>>> However, I'm afraid the following commit may have nullified > >>>> your patch. > >>>> > >>>> https://github.com/acpica/acpica/commit/8149df49 > >>> > >>> It looks to only be adjusting the preference for the Address > >>> portion. It still uses the length field from FADT and doesn't > >>> use the length from the GAS. > >> > >> Okay. > >> > >> BTW, I just read your patch carefully but I failed to understand > >> how shutting up a warning can fix any problem at all. Did you > >> mean to patch internal table? > > > > It shuts up the second warning. The first warning is still legit > > (there is a length mismatch), but it handles the special case of > > the 32-bit length being zero by using the 64-bit length. Once a > > valid length is set, the second warning goes away > > Yes, I know that. > > > (and GPE1 works which apparently fixes resume for Sean). > > It is really puzzling because your patch does not change anything > functionally but shutting up the warning message. :-( 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? -- John Baldwin