Re: Investigating failed suspend/resume T61

2014-06-07 Thread Edward Tomasz Napierała
With modem enabled?  I don't know; I don't see anything related to hdac0
during resume.  With modem disabled resuming is completely broken - it
fails _very_ early, by failing to return from acpi_machdep_sleep() iirc.

On 0607T1221, Adrian Chadd wrote:
 That's odd. Is it still trying to resume hdac0 ?
 
 
 -a
 
 
 On 6 June 2014 03:57, Edward Tomasz Napierała tr...@freebsd.org wrote:
  The difference in dmesg with (-) and without (+) the modem looks like this:
 
  --- dmesg.modem 2014-06-06 09:46:02.0 +0200
  +++ dmesg.bez   2014-06-06 09:52:45.0 +0200
  @@ -48,7 +48,7 @@ Event timer HPET1 frequency 14318180 H
   Event timer HPET2 frequency 14318180 Hz quality 440
   atrtc0: AT realtime clock port 0x70-0x71 irq 8 on acpi0
   Event timer RTC frequency 32768 Hz quality 0
  -Timecounter ACPI-fast frequency 3579545 Hz quality 900
  +Timecounter ACPI-safe frequency 3579545 Hz quality 850
   acpi_timer0: 24-bit timer at 3.579545MHz port 0x1008-0x100b on acpi0
   acpi_lid0: Control Method Lid Switch on acpi0
   acpi_button0: Sleep Button on acpi0
  @@ -157,12 +157,13 @@ est0: Enhanced SpeedStep Frequency Cont
   coretemp1: CPU On-Die Thermal Sensors on cpu1
   est1: Enhanced SpeedStep Frequency Control on cpu1
   Timecounters tick every 1.000 msec
  +hdac0: Command timeout on address 1
  +hdac0: Command timeout on address 1
  +hdac0: CODEC is not responding!
   hdacc0: Analog Devices AD1984 HDA CODEC at cad 0 on hdac0
   hdaa0: Analog Devices AD1984 Audio Function Group at nid 1 on hdacc0
   pcm0: Analog Devices AD1984 (Analog 2.0+HP/2.0) at nid 18,17 and 
  28,20,21 on hdaa0
   pcm1: Analog Devices AD1984 (Ext-Rear Digital) at nid 27 on hdaa0
  -hdacc1: Conexant (0x2bfa) HDA CODEC at cad 1 on hdac0
  -unknown: Conexant (0x2bfa) HDA CODEC Modem Function Group at nid 2 on 
  hdacc1 (no driver attached)
   random: unblocking device.
   usbus0: 12Mbps Full Speed USB v1.0
   usbus1: 12Mbps Full Speed USB v1.0
 
  Note that with modem disabled, it's not suspend that fails - it's the
  resuming.
 
  On 0605T2152, Adrian Chadd wrote:
  ok so when you disable the modem, does it still think there's a modem
  there? Is it still trying to power the device off via ACPI even though
  it's not probed?
 
 
  -a
 
 
  On 5 June 2014 10:50, Sean Bruno sbr...@ignoranthack.me wrote:
   On Wed, 2014-06-04 at 15:32 -0700, Adrian Chadd wrote:
   Hi,
  
   Please also document why it is/isn't working. It's only documented as
   suspend/resume doesn't work :)
  
  
   -a
  
  
   Well there's this that trasz updated to indicate that it works:
   https://wiki.freebsd.org/SuspendResume
  
   I just updated this to indicate the same information:
   https://wiki.freebsd.org/Laptops/Thinkpad_T61
  
   sean
  
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org

Re: Investigating failed suspend/resume T61

2014-06-06 Thread Edward Tomasz Napierała
The difference in dmesg with (-) and without (+) the modem looks like this:

--- dmesg.modem 2014-06-06 09:46:02.0 +0200
+++ dmesg.bez   2014-06-06 09:52:45.0 +0200
@@ -48,7 +48,7 @@ Event timer HPET1 frequency 14318180 H
 Event timer HPET2 frequency 14318180 Hz quality 440
 atrtc0: AT realtime clock port 0x70-0x71 irq 8 on acpi0
 Event timer RTC frequency 32768 Hz quality 0
-Timecounter ACPI-fast frequency 3579545 Hz quality 900
+Timecounter ACPI-safe frequency 3579545 Hz quality 850
 acpi_timer0: 24-bit timer at 3.579545MHz port 0x1008-0x100b on acpi0
 acpi_lid0: Control Method Lid Switch on acpi0
 acpi_button0: Sleep Button on acpi0
@@ -157,12 +157,13 @@ est0: Enhanced SpeedStep Frequency Cont
 coretemp1: CPU On-Die Thermal Sensors on cpu1
 est1: Enhanced SpeedStep Frequency Control on cpu1
 Timecounters tick every 1.000 msec
+hdac0: Command timeout on address 1
+hdac0: Command timeout on address 1
+hdac0: CODEC is not responding!
 hdacc0: Analog Devices AD1984 HDA CODEC at cad 0 on hdac0
 hdaa0: Analog Devices AD1984 Audio Function Group at nid 1 on hdacc0
 pcm0: Analog Devices AD1984 (Analog 2.0+HP/2.0) at nid 18,17 and 28,20,21 on 
hdaa0
 pcm1: Analog Devices AD1984 (Ext-Rear Digital) at nid 27 on hdaa0
-hdacc1: Conexant (0x2bfa) HDA CODEC at cad 1 on hdac0
-unknown: Conexant (0x2bfa) HDA CODEC Modem Function Group at nid 2 on hdacc1 
(no driver attached)
 random: unblocking device.
 usbus0: 12Mbps Full Speed USB v1.0
 usbus1: 12Mbps Full Speed USB v1.0

Note that with modem disabled, it's not suspend that fails - it's the
resuming.

On 0605T2152, Adrian Chadd wrote:
 ok so when you disable the modem, does it still think there's a modem
 there? Is it still trying to power the device off via ACPI even though
 it's not probed?
 
 
 -a
 
 
 On 5 June 2014 10:50, Sean Bruno sbr...@ignoranthack.me wrote:
  On Wed, 2014-06-04 at 15:32 -0700, Adrian Chadd wrote:
  Hi,
 
  Please also document why it is/isn't working. It's only documented as
  suspend/resume doesn't work :)
 
 
  -a
 
 
  Well there's this that trasz updated to indicate that it works:
  https://wiki.freebsd.org/SuspendResume
 
  I just updated this to indicate the same information:
  https://wiki.freebsd.org/Laptops/Thinkpad_T61
 
  sean
 
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org


Re: Investigating failed suspend/resume T61

2014-06-05 Thread Sean Bruno
On Wed, 2014-06-04 at 15:32 -0700, Adrian Chadd wrote:
 Hi,
 
 Please also document why it is/isn't working. It's only documented as
 suspend/resume doesn't work :)
 
 
 -a


Well there's this that trasz updated to indicate that it works:
https://wiki.freebsd.org/SuspendResume

I just updated this to indicate the same information:
https://wiki.freebsd.org/Laptops/Thinkpad_T61

sean

___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org


Re: Investigating failed suspend/resume T61

2014-06-05 Thread Adrian Chadd
ok so when you disable the modem, does it still think there's a modem
there? Is it still trying to power the device off via ACPI even though
it's not probed?


-a


On 5 June 2014 10:50, Sean Bruno sbr...@ignoranthack.me wrote:
 On Wed, 2014-06-04 at 15:32 -0700, Adrian Chadd wrote:
 Hi,

 Please also document why it is/isn't working. It's only documented as
 suspend/resume doesn't work :)


 -a


 Well there's this that trasz updated to indicate that it works:
 https://wiki.freebsd.org/SuspendResume

 I just updated this to indicate the same information:
 https://wiki.freebsd.org/Laptops/Thinkpad_T61

 sean

___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org


Re: Investigating failed suspend/resume T61

2014-06-04 Thread Edward Tomasz Napierała
Wiadomość napisana przez John Baldwin w dniu 4 cze 2014, o godz. 19:30:

 On Wednesday, June 04, 2014 1:17:14 pm Edward Tomasz Napierała wrote:
 On 0604T0907, Sean Bruno wrote:
 On Thu, 2014-05-29 at 09:30 -0400, John Baldwin wrote:
 On Thursday, May 29, 2014 9:16:41 am Sean Bruno wrote:
 On Wed, 2014-05-28 at 18:43 -0400, Jung-uk Kim wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 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)?
 
 BTW, ACPI 5.0a (page 121) says:
 
 This is an optional field; if this register block is not supported,
 this field contains zero.
 
 Therefore, we must assume X_GPE1_BLK it is NOT supported.
 
 Jung-uk Kim
 
 So, reverting John's changes and applying yours seems to do new things
 while not quieting the old error messages.  Perhaps this is significant?
 
 real memory  = 2147483648 (2048 MB)
 avail memory = 2007089152 (1914 MB)
 Event timer LAPIC quality 400
 ACPI APIC Table: LENOVO TP-7U   
 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: 0x102C/0x0 (20130823/tbfadt-630)
 ioapic0: Changing APIC ID to 1
 ioapic0 Version 2.0 irqs 0-23 on motherboard
 random: Software, Yarrow initialized
 kbd1 at kbdmux0
 acpi0: LENOVO TP-7U on motherboard
 CPU0: local APIC error 0x40
 ACPI Error: GPE0 block (GPE 0 to 31) overlaps the GPE1 block (GPE 0 to
 15) - Ignoring GPE1 (20130823/evgpeinit-178)
 
 Actually, I think all these patches are changing nothing, and this actually
 points out that I misread your FADT at the first.  GPE1 should actually be
 ignored since it does in fact overlap.  Can you just try reverting all your
 changes and seeing if suspend/resume works?
 
 
 
 Boy oh boy ... talk about a waste of time.
 
 trasz@ and I have the same laptop and I just confirmed with him that the
 patch does nothing useful (as both of you suggested).  The *ACTUAL*
 problem seems to be related to disabling devices in the Thinkpad BIOS.
 
 
 Yup.  The culprit seems to be the Security - IO Port Access - Modem
 BIOS control: setting it to disabled breaks resume; the AcpiEnterSleepState()
 never returns.
 
 With that option set to enabled, the suspend/resume works seems to work
 flawlessly on T61 with Intel graphics, with VT kernel and i915kms.ko,
 on 11-CURRENT/amd64 from a few days ago, without any patches or special
 sysctl/tunables. 
 
 Well, document it on the wiki at least.

Thanks for suggestion; done.

___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org


Re: Investigating failed suspend/resume T61

2014-05-29 Thread Sean Bruno
On Wed, 2014-05-28 at 18:43 -0400, Jung-uk Kim wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 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)?
 
 BTW, ACPI 5.0a (page 121) says:
 
 This is an optional field; if this register block is not supported,
 this field contains zero.
 
 Therefore, we must assume X_GPE1_BLK it is NOT supported.
 
 Jung-uk Kim

So, reverting John's changes and applying yours seems to do new things
while not quieting the old error messages.  Perhaps this is significant?

real memory  = 2147483648 (2048 MB)
avail memory = 2007089152 (1914 MB)
Event timer LAPIC quality 400
ACPI APIC Table: LENOVO TP-7U   
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: 0x102C/0x0 (20130823/tbfadt-630)
ioapic0: Changing APIC ID to 1
ioapic0 Version 2.0 irqs 0-23 on motherboard
random: Software, Yarrow initialized
kbd1 at kbdmux0
acpi0: LENOVO TP-7U on motherboard
CPU0: local APIC error 0x40
ACPI Error: GPE0 block (GPE 0 to 31) overlaps the GPE1 block (GPE 0 to
15) - Ignoring GPE1 (20130823/evgpeinit-178)
acpi_ec0: Embedded Controller: GPE 0x12, ECDT port 0x62,0x66 on acpi0
acpi0: Power Button (fixed)
acpi0: reservation of 0, a (3) failed
acpi0: reservation of 10, 7df0 (3) failed


___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org


Re: Investigating failed suspend/resume T61

2014-05-29 Thread John Baldwin
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
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org


Re: Investigating failed suspend/resume T61

2014-05-28 Thread Sean Bruno
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=0xbfebfbffFPU,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=0xe3bdSSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM
  AMD Features=0x20100800SYSCALL,NX,LM
  AMD Features2=0x1LAHF
  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: 0x102C/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)


sean

___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org


Re: Investigating failed suspend/resume T61

2014-05-28 Thread John Baldwin
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=0xbfebfbffFPU,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=0xe3bdSSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM
   AMD Features=0x20100800SYSCALL,NX,LM
   AMD Features2=0x1LAHF
   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: 0x102C/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.)

-- 
John Baldwin
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org


Re: Investigating failed suspend/resume T61

2014-05-28 Thread John Baldwin
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=0xbfebfbffFPU,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=0xe3bdSSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM
 AMD Features=0x20100800SYSCALL,NX,LM
 AMD Features2=0x1LAHF
 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: 0x102C/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?

-- 
John Baldwin
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org


Re: Investigating failed suspend/resume T61

2014-05-28 Thread Jung-uk Kim
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

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=0xbfebfbffFPU,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=0xe3bdSSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM
 AMD Features=0x20100800SYSCALL,NX,LM AMD
 Features2=0x1LAHF 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-7LFreeBSD/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: 0x102C/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

Jung-uk Kim
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (FreeBSD)

iQEcBAEBAgAGBQJThhJ8AAoJEHyflib82/FGrPsH/iohXslK+ZSWBWXpHmlE5ONQ
bpRjFbAvfeKwSn33YaVgk/1g06/+UhPcpErEwLF0yp9/CC54v40/LXJUKs2DTYRV
5A2gK02xTJ9vJCQiqJXanZhdFBfITPf9eKAM2idIfgCwGlvKH/Vw3DFZbdVHDphJ
ma4nWYFWureASD3QvRoZ4xjmjWZoY0jfw/h+xRk49Ja5/bzFTu9Mx0AbkVTtg/50
jta4pzbaiv6Sv3lsTvYU+VTc9vOyLqnPl6JSeavM8Bit3AThb8e8Atg7ZLxb6WGb
YAdei45YvsplGTTl+vjzOWFpXdxNATv2yjwBNzudG1+rjiCEayd+96CyMURH+tk=
=ylP0
-END PGP SIGNATURE-
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org


Re: Investigating failed suspend/resume T61

2014-05-28 Thread John Baldwin
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=0xbfebfbffFPU,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=0xe3bdSSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM
  AMD Features=0x20100800SYSCALL,NX,LM AMD
  Features2=0x1LAHF 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-7LFreeBSD/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: 0x102C/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.

-- 
John Baldwin
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org


Re: Investigating failed suspend/resume T61

2014-05-28 Thread Jung-uk Kim
-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=0xbfebfbffFPU,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=0xe3bdSSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM
 AMD Features=0x20100800SYSCALL,NX,LM AMD 
 Features2=0x1LAHF 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-7LFreeBSD/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: 0x102C/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

Re: Investigating failed suspend/resume T61

2014-05-28 Thread John Baldwin
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=0xbfebfbffFPU,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=0xe3bdSSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM
  AMD Features=0x20100800SYSCALL,NX,LM AMD
  Features2=0x1LAHF 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-7LFreeBSD/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: 0x102C/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

Re: Investigating failed suspend/resume T61

2014-05-28 Thread Jung-uk Kim
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2014-05-28 18:14:34 -0400, 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. ...
 ^
not

Sorry for the typo.

Jung-uk Kim
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (FreeBSD)

iQEcBAEBAgAGBQJThmG3AAoJEHyflib82/FGlGEIAIZBOaLiQSpFT8ziuK8vPP7s
WwI69o7tYzso16pbBjtaCV7eSD2uku+inSqNigmnp+FwvZGr4wxTOQSYMLSht9kw
CkiEjZ2wN4xA5rTCfvZzHlUgnVk4M9DAXjILiZ5W6+aURo5xRwkFNjVVQXPh2JXn
/JwmP7yJrRyVcm3KGKTR1c3rqoBzps3RP9RSz7I2bPZwzRfBTTTgiuuAjDy3LdUf
ozz6zGkknTGg/tPSATZULPWrzhfVWjfzwsTO3MbzQwynXtjVa0nmAO0Ug0iBiB0g
9ls1TdH/JSwaMMG3/8QlIkMp95jD5aTtpT2x1I78iWbptEX5N4pJ7uQctsFn09o=
=j9xm
-END PGP SIGNATURE-
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org


Re: Investigating failed suspend/resume T61

2014-05-28 Thread Jung-uk Kim
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

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)?

BTW, ACPI 5.0a (page 121) says:

This is an optional field; if this register block is not supported,
this field contains zero.

Therefore, we must assume X_GPE1_BLK it is NOT supported.

Jung-uk Kim
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (FreeBSD)

iQEcBAEBAgAGBQJThmauAAoJEHyflib82/FG0rUIAJdLFd+Bd5KXF5nzSX9maVS2
71h9iM5oJE6WjLdMAt7nD2p1seiicVYkxm+jLU08EegkV9QH3506wt8KOXxtvIMG
XNuLzTB7cukqYoMXfsrA2ojis4YDGADhAwuT6UpsJq8iblwiA4Ec9pvfli4l/RwU
UObGkQIbKJ1BLspFHFClbXrqBqCp5Ou6s8Aga0AsqR4BIqgpnrtV+LQEmPIiUCRh
W3PLu+/VHmBvTaU7YhUhmsN0BDC1CXhGwi6w614uHWB9GBym7xIuFjjREMoLPX2D
cL9gidZBj0TAtPj2oe/geYRb3Ta47Migo/FAkkpp5hqd9/xrr9CImK9f37yzqzU=
=Yxlz
-END PGP SIGNATURE-
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org


Re: Investigating failed suspend/resume T61

2014-05-28 Thread Jung-uk Kim
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2014-05-28 18:14:34 -0400, Jung-uk Kim wrote:
 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) { ...

Please see the attached patch (not tested).  Probably, this is what
you really meant to test.

Jung-uk Kim
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (FreeBSD)

iQEcBAEBAgAGBQJThnPaAAoJEHyflib82/FGKbcIAIfNGtaEDNhEuGUTTr7wSgCE
DIAIt/QdTeICyOiR8t9r8SrOKrnrloPohKTqtujhkliiAN7bKbjodeN3+/50H7a9
Ura6075gCtds/6Im/hOiFMyclWBA88HR+lUpct3RJD9Ag70qcfEQloIiVI1pkm2U
X1YRRgS0liUbG4NKoZuAl2xPxyO+DS+jC7FKO/Ti4Bl4buM+R/lO0fvAj6ZZoRQ4
JnLGsOPMrmPLDfug6dZSCruG8rcetrh+0PYVn3En4ecZ8rzsY+IW5qR+57+8rcXX
Jh9JsWyS0eYiGP62yOKzdj+9GSH85MJJC0fvtOgYe42eA8UU3bf8GAD5Vynl+gU=
=4thP
-END PGP SIGNATURE-
Index: sys/contrib/dev/acpica/components/events/evgpeinit.c
===
--- sys/contrib/dev/acpica/components/events/evgpeinit.c	(리비전 266821)
+++ sys/contrib/dev/acpica/components/events/evgpeinit.c	(작업 사본)
@@ -128,12 +128,19 @@ AcpiEvGpeInitialize (
  * If EITHER the register length OR the block address are zero, then that
  * particular block is not supported.
  */
-if (AcpiGbl_FADT.Gpe0BlockLength 
-AcpiGbl_FADT.XGpe0Block.Address)
+if ((AcpiGbl_FADT.Gpe0Block  AcpiGbl_FADT.Gpe0BlockLength) ||
+(AcpiGbl_FADT.XGpe0Block.Address  AcpiGbl_FADT.XGpe0Block.BitWidth))
 {
 /* GPE block 0 exists (has both length and address  0) */
 
-RegisterCount0 = (UINT16) (AcpiGbl_FADT.Gpe0BlockLength / 2);
+if (AcpiGbl_FADT.XGpe0Block.Address  AcpiGbl_FADT.XGpe0Block.BitWidth)
+{
+RegisterCount0 = ACPI_DIV_8 (AcpiGbl_FADT.XGpe0Block.BitWidth) / 2;
+}
+else
+{
+RegisterCount0 = AcpiGbl_FADT.Gpe0BlockLength / 2;
+}
 GpeNumberMax = (RegisterCount0 * ACPI_GPE_REGISTER_WIDTH) - 1;
 
 /* Install GPE Block 0 */
@@ -149,12 +156,19 @@ AcpiEvGpeInitialize (
 }
 }
 
-if (AcpiGbl_FADT.Gpe1BlockLength 
-AcpiGbl_FADT.XGpe1Block.Address)
+if ((AcpiGbl_FADT.Gpe1Block  AcpiGbl_FADT.Gpe1BlockLength) ||
+(AcpiGbl_FADT.XGpe1Block.Address  AcpiGbl_FADT.XGpe1Block.BitWidth))
 {
 /* GPE block 1 exists (has both length and address  0) */
 
-RegisterCount1 = (UINT16) (AcpiGbl_FADT.Gpe1BlockLength / 2);
+if (AcpiGbl_FADT.XGpe1Block.Address  AcpiGbl_FADT.XGpe1Block.BitWidth)
+{
+RegisterCount1 = ACPI_DIV_8 (AcpiGbl_FADT.XGpe1Block.BitWidth) / 2;
+}
+else
+{
+RegisterCount1 = AcpiGbl_FADT.Gpe1BlockLength / 2;
+}
 
 /* Check for GPE0/GPE1 overlap (if both banks exist) */
 
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org

Re: Investigating failed suspend/resume T61

2014-05-27 Thread Sean Bruno
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=0xbfebfbffFPU,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=0xe3bdSSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM
AMD Features=0x20100800SYSCALL,NX,LM
AMD Features2=0x1LAHF
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: 0x102C/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

sean

___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org


Re: Investigating failed suspend/resume T61

2014-05-27 Thread John Baldwin
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=0xbfebfbffFPU,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=0xe3bdSSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM
 AMD Features=0x20100800SYSCALL,NX,LM
 AMD Features2=0x1LAHF
 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: 0x102C/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)


-- 
John Baldwin
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org