Re: Immediately resumes after hibernate
On Wed, Jul 30, 2014 at 12:29:00PM -0700, Mike Larkin wrote:
That's good news, but unfortunately it's just a diagnostic tool to indicate
what I already suspected - a GPE is firing, but it's still unknown which one.
So, I modified the conditional in acpi_enable_wakegpes in acpi.c to exclude
sets of wakeup devices. Eventually I landed on:
void
acpi_enable_wakegpes(struct acpi_softc *sc, int state)
{
struct acpi_wakeq *wentry;
SIMPLEQ_FOREACH(wentry, sc-sc_wakedevs, q_next) {
dnprintf(10, %.4s(S%d) gpe %.2x\n, wentry-q_node-name,
wentry-q_state,
wentry-q_gpe);
if ((state = wentry-q_state)
(strncmp(SLPB, wentry-q_node-name, 4) != 0))
acpi_enable_onegpe(sc, wentry-q_gpe);
}
}
What is SLPB? I'll try to find out for myself, but just wanted to share
my progress.
Elijah
Re: Immediately resumes after hibernate
On Thu, Jul 31, 2014 at 10:10:59AM -0400, Elijah Buck wrote:
On Wed, Jul 30, 2014 at 12:29:00PM -0700, Mike Larkin wrote:
That's good news, but unfortunately it's just a diagnostic tool to indicate
what I already suspected - a GPE is firing, but it's still unknown which
one.
So, I modified the conditional in acpi_enable_wakegpes in acpi.c to exclude
sets of wakeup devices. Eventually I landed on:
void
acpi_enable_wakegpes(struct acpi_softc *sc, int state)
{
struct acpi_wakeq *wentry;
SIMPLEQ_FOREACH(wentry, sc-sc_wakedevs, q_next) {
dnprintf(10, %.4s(S%d) gpe %.2x\n, wentry-q_node-name,
wentry-q_state,
wentry-q_gpe);
if ((state = wentry-q_state)
(strncmp(SLPB, wentry-q_node-name, 4) != 0))
acpi_enable_onegpe(sc, wentry-q_gpe);
}
}
What is SLPB? I'll try to find out for myself, but just wanted to share
my progress.
Elijah
Sleep Button most likely. But you'd need to look at the AML to be sure.
Do you have a sleep button on the case or keyboard?
-ml
Re: Immediately resumes after hibernate
Sleep Button most likely. But you'd need to look at the AML to be sure. Do you have a sleep button on the case or keyboard? Nope. Just a single power button. Nothing on the keyboard.
Re: Immediately resumes after hibernate
On Tue, Jul 29, 2014 at 10:14:40AM -0400, Elijah Buck wrote: I have a whitebox desktop with a Biostar TH55B HD motherboard. Hibernate (via ZZZ) works great, as does resume. However, when hibernating, the system briefly powers off and then immediately starts back up. The issue occurs both on 5.5 amd64 and 5.6-beta (Jul 27) amd64. I tried setting the BIOS to use ACPI v1.0, v2.0, v3.0 with no effect. I tried removing usb devices, in case they were waking the system. Hibernate in Windows 8.1 works. What might the problem be? I've got a machine with the same symptoms with very similar hardware. It doesn't fire any GPEs on resume, and the fixed function buttons aren't set either. So the reason for resume is still a mystery. 1. Please send an acpidump. 2. In dev/acpi/acpi.c, try commenting out the following line: acpi_enable_wakegpes(sc, state); ... in my tree that's on line 2157. Note there are two occurrences of that line of code, you want to comment out the one in acpi_sleep_state and not acpi_powerdown. Then rebuild/reinstall the kernel and see if ZZZ works - that change will disable the wake devices -ml Thanks, Elijah dmesg below (for the snapshot I am now running): OpenBSD 5.6-beta (GENERIC.MP) #305: Sun Jul 27 19:02:25 MDT 2014 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8530690048 (8135MB) avail mem = 8294817792 (7910MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xfc620 (66 entries) bios0: vendor American Megatrends Inc. version 080015 date 10/15/2010 bios0: BIOSTAR Group TH55B HD acpi0 at bios0: rev 0 acpi0: sleep states S0 S1 S4 S5 acpi0: tables DSDT FACP APIC MCFG OEMB SSDT acpi0: wakeup devices P0P1(S4) P0P3(S4) P0P4(S4) P0P5(S4) P0P6(S4) BR1E(S4) UAR1(S4) PS2K(S4) PS2M(S4) EUSB(S4) USB0(S4) USB1(S4) USB2(S4) USB3(S4) USBE(S4) USB4(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i5 CPU 750 @ 2.67GHz, 2745.42 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,LONG,LAHF,PERF,ITSC cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 137MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.1.0, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i5 CPU 750 @ 2.67GHz, 2745.04 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,LONG,LAHF,PERF,ITSC cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Core(TM) i5 CPU 750 @ 2.67GHz, 2745.04 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,LONG,LAHF,PERF,ITSC cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Core(TM) i5 CPU 750 @ 2.67GHz, 2745.04 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,LONG,LAHF,PERF,ITSC cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 0, core 3, package 0 ioapic0 at mainbus0: apid 7 pa 0xfec0, version 20, 24 pins ioapic0: misconfigured as apic 1, remapped to apid 7 acpimcfg0 at acpi0 addr 0xe000, bus 0-255 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (P0P4) acpiprt2 at acpi0: bus 5 (BR1E) acpiprt3 at acpi0: bus 2 (BR20) acpiprt4 at acpi0: bus -1 (BR22) acpiprt5 at acpi0: bus -1 (BR23) acpiprt6 at acpi0: bus 3 (BR24) acpiprt7 at acpi0: bus 4 (BR25) acpiprt8 at acpi0: bus -1 (BR26) acpiprt9 at acpi0: bus -1 (BR27) acpicpu0 at acpi0: C3, C2, C1, PSS acpicpu1 at acpi0: C3, C2, C1, PSS acpicpu2 at acpi0: C3, C2, C1, PSS acpicpu3 at acpi0: C3, C2, C1, PSS acpitz0 at acpi0: critical temperature is 85 degC acpibtn0 at acpi0: SLPB acpibtn1 at acpi0: PWRB cpu0: Enhanced SpeedStep 2745 MHz: speeds: 2668, 2667, 2533, 2400, 2267, 2133, 2000, 1867, 1733, 1600, 1467, 1333, 1200 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 Intel Core DMI rev 0x11 ppb0 at pci0 dev 3 function 0 Intel Core PCIE rev 0x11 pci1 at ppb0 bus 1 radeondrm0 at pci1 dev 0 function 0 ATI Radeon HD 5750 rev 0x00 drm0 at radeondrm0 radeondrm0: msi azalia0 at pci1 dev 0 function 1 ATI Radeon HD 5700
Re: Immediately resumes after hibernate
On Wed, Jul 30, 2014 at 01:26:06AM -0700, Mike Larkin wrote: I've got a machine with the same symptoms with very similar hardware. It doesn't fire any GPEs on resume, and the fixed function buttons aren't set either. So the reason for resume is still a mystery. 1. Please send an acpidump. 2. In dev/acpi/acpi.c, try commenting out the following line: acpi_enable_wakegpes(sc, state); ... in my tree that's on line 2157. Note there are two occurrences of that line of code, you want to comment out the one in acpi_sleep_state and not acpi_powerdown. Then rebuild/reinstall the kernel and see if ZZZ works - that change will disable the wake devices -ml The change to dev/acpi/acpi.c works perfectly. I am attaching a tar of the apcidump output (which will of course be stripped by the list). Let me know if there's another way you'd like me to send it. Thanks, Elijah [demime 1.01d removed an attachment of type application/x-tar]
Re: Immediately resumes after hibernate
On Wed, Jul 30, 2014 at 11:07:27AM -0400, Elijah Buck wrote: On Wed, Jul 30, 2014 at 01:26:06AM -0700, Mike Larkin wrote: I've got a machine with the same symptoms with very similar hardware. It doesn't fire any GPEs on resume, and the fixed function buttons aren't set either. So the reason for resume is still a mystery. 1. Please send an acpidump. 2. In dev/acpi/acpi.c, try commenting out the following line: acpi_enable_wakegpes(sc, state); ... in my tree that's on line 2157. Note there are two occurrences of that line of code, you want to comment out the one in acpi_sleep_state and not acpi_powerdown. Then rebuild/reinstall the kernel and see if ZZZ works - that change will disable the wake devices -ml The change to dev/acpi/acpi.c works perfectly. That's good news, but unfortunately it's just a diagnostic tool to indicate what I already suspected - a GPE is firing, but it's still unknown which one. The spec is a little unclear here (gee, what a surprise). It only says that the implementation must provide a way for OSPM to determine the GPE that fired to wake the machine up. But it doesn't say what that way is. A few weeks ago I cooked up a diff to read the GPE status right on wake (from S3) and on the machines I have that immediately wake from S3, it didn't show any GPE as signaled. We can't use the same approach on wake from S4 because of all the other stuff that happens before we can read the GPE registers. The change I recommended can't be committed as is. But it does help point things in the right direction. I'll take a look at the AML and see if I can see a suspect GPE. -ml I am attaching a tar of the apcidump output (which will of course be stripped by the list). Let me know if there's another way you'd like me to send it. Thanks, Elijah [demime 1.01d removed an attachment of type application/x-tar]
Re: Immediately resumes after hibernate
Wed, Jul 30, 2014 at 12:29:00PM -0700, Mike Larkin wrote: That's good news, but unfortunately it's just a diagnostic tool to indicate what I already suspected - a GPE is firing, but it's still unknown which one. The spec is a little unclear here (gee, what a surprise). It only says that the implementation must provide a way for OSPM to determine the GPE that fired to wake the machine up. But it doesn't say what that way is. A few weeks ago I cooked up a diff to read the GPE status right on wake (from S3) and on the machines I have that immediately wake from S3, it didn't show any GPE as signaled. We can't use the same approach on wake from S4 because of all the other stuff that happens before we can read the GPE registers. The change I recommended can't be committed as is. But it does help point things in the right direction. I'll take a look at the AML and see if I can see a suspect GPE. -ml Is it possible to disable individual wakeup devices? (acpi0: wakeup devices P0P1(S4) P0P3(S4) P0P4(S4) P0P5(S4) P0P6(S4) BR1E(S4) UAR1(S4) PS2K(S4) PS2M(S4) EUSB(S4) USB0(S4) USB1(S4) USB2(S4) USB3(S4) USBE(S4) USB4(S4) [...]). Would that help track down where the GPE is coming from? Elijah
