From owner-freebsd-acpi@FreeBSD.ORG Wed May 28 18:16:04 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from hammer.pct.niksun.com (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by hub.freebsd.org (Postfix) with ESMTP id 64AF0E75; Wed, 28 May 2014 18:16:04 +0000 (UTC) Message-ID: <538627E3.7080308@FreeBSD.org> Date: Wed, 28 May 2014 14:16:03 -0400 From: Jung-uk Kim User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: John Baldwin Subject: Re: Investigating failed suspend/resume T61 References: <1400861698.1126.0.camel@bruno> <201405281220.24778.jhb@freebsd.org> <5386127C.3060005@FreeBSD.org> <201405281344.46430.jhb@freebsd.org> In-Reply-To: <201405281344.46430.jhb@freebsd.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 18:16:04 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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? Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQEcBAEBAgAGBQJThifjAAoJEHyflib82/FGNsEIAI2/4zlCl4J448VDzRPlzp7i jsHVt9KB7NUNin3Wie20PwxHxLhWcxd4LsMXUuC5vQUO7d8i06AMImsJ4O56u1ZO muGu/tuH9RfmH7xBeJ/9Lu7FOSUhEPd4qIQwl0hD1P5OTmigdJDQ9W0Xw4l87VuH EuHWM0DiXywAvZTKgPdc4REZHzO2PnVco7qm/HpJqcxksrmOMbWuPjlimnR4KSQT JFf6Gp3+xtFgP3Mpcqfyn3Xi8hO8DEkVBOQVkAh9u3Rki1AZuBjPwkWop0ykTjT7 KL5UAv7Tx/4W04tbqzsE3lmvCdU5EcNjhSlFEmKA5oyOoNdyf7NNAz3fmMMkU2I= =OrGY -----END PGP SIGNATURE-----