Date: Wed, 28 May 2014 15:56:37 -0400 From: John Baldwin <jhb@freebsd.org> To: "Jung-uk Kim" <jkim@freebsd.org> Cc: "freebsd-acpi@freebsd.org" <freebsd-acpi@freebsd.org> Subject: Re: Investigating failed suspend/resume T61 Message-ID: <201405281556.37651.jhb@freebsd.org> In-Reply-To: <538627E3.7080308@FreeBSD.org> References: <1400861698.1126.0.camel@bruno> <201405281344.46430.jhb@freebsd.org> <538627E3.7080308@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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<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 (and GPE1 works which apparently fixes resume for Sean). -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201405281556.37651.jhb>