Investigating failed suspend/resume T61
Jung-uk Kim
jkim at FreeBSD.org
Wed May 28 20:06:55 UTC 2014
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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 at 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<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>
>>>
>>
>
Features2=0xe3bd<SSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM>
>>>>>>>>>>>> AMD Features=0x20100800<SYSCALL,NX,LM> AMD
>>>>>>>>>>>> Features2=0x1<LAHF> TSC: P-state invariant,
>>>>>>>>>>>> performance statistics real memory =
>>>>>>>>>>>> 2147483648 (2048 MB) avail memory =
>>>>>>>>>>>> 2007138304 (1914 MB) Event timer "LAPIC"
>>>>>>>>>>>> quality 400 ACPI APIC Table: <LENOVO TP-7L
>>>>>>>>>>>> > 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. :-(
Jung-uk Kim
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (FreeBSD)
iQEcBAEBAgAGBQJThkHeAAoJEHyflib82/FGC+YH/1rlo23HKXhrZVqGeP8zKsP/
OQj7rcF3sX0bvCymX/iq/I0IXLlAiZna/FRo+vq4RaL0gRHEefPdhg5z/K0UGd7l
00B3tgUhQglp0SooHCl+I97+9otHRCgSrlhQ1RCmIrMxlb+057Qn92GV6fGFpFTO
f/NMrUp3SGmp/wI44B5KHryitoGJYvFEPkTA1uL2UkHzCqL313uOBIU2jtGPtqo4
cbCgiSPkfovbjM1qKBsyD2htme0k7Zqc734nFfT+ZxJEw5y2V6HUNCSnfmR520jk
BRLGBsNJ1Xh3sIcE3QgEAueFnutYKsyOgOzbJp6Kjo8FXHHgaUcd5lSBtqo5pf4=
=dTxX
-----END PGP SIGNATURE-----
More information about the freebsd-acpi
mailing list