Bug 263557 - ACPI S3 doesn't resume on a MateBook X Pro 2021
Summary: ACPI S3 doesn't resume on a MateBook X Pro 2021
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 13.1-STABLE
Hardware: amd64 Any
: --- Affects Some People
Assignee: freebsd-acpi (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-04-25 08:54 UTC by Patrick Mackinlay
Modified: 2024-06-08 02:05 UTC (History)
3 users (show)

See Also:


Attachments
dmesg.boot (5.88 KB, text/plain)
2022-04-25 08:54 UTC, Patrick Mackinlay
no flags Details
/var/log/messages on suspend (9.08 KB, text/plain)
2022-04-25 08:55 UTC, Patrick Mackinlay
no flags Details
/var/log/messages on suspend test (4.45 KB, text/plain)
2022-04-25 08:56 UTC, Patrick Mackinlay
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Patrick Mackinlay 2022-04-25 08:54:49 UTC
Created attachment 233469 [details]
dmesg.boot

I have a MateBook X Pro 2021 with FreeBSD installed, ACPI S3 doesn't work, when I run

acpiconf -s 3

the laptop appears to suspend fine, however it will not resume. When I press the power button to resume the screen stays blank and eventually (after a couple of minutes) the machine just reboots normally.
After booting back to FreeBSD the last entry in /var/log/messages is the suspend message.

The laptop suspends and resumes fine on linux.

I tried building a minimal test kernel (MINIMAL config with NO_MODULES and nvme and nvd devices added). I used FreeBSD 13 stable (commit bb8e1dfbff30e5df97fa31c88f8218af054fe166). The test kernel had the same issues.

Debugging with:

sysctl debug.bootverbose=1
sysctl debug.acpi.suspend_bounce=1
acpiconf -s 3

worked fine.

I have attached the dmesg.boot, and the /var/log/messages for the suspend/resume trial (messages.on.suspend) and for when I tried debugging (messages.on.suspend.test). All theses were taken with the minimal test kernel.
Comment 1 Patrick Mackinlay 2022-04-25 08:55:36 UTC
Created attachment 233470 [details]
/var/log/messages on suspend
Comment 2 Patrick Mackinlay 2022-04-25 08:56:02 UTC
Created attachment 233471 [details]
/var/log/messages on suspend test
Comment 3 Graham Perrin freebsd_committer freebsd_triage 2022-04-26 18:34:39 UTC
What's the graphics hardware?
Comment 4 Patrick Mackinlay 2022-04-26 21:22:41 UTC
Its using the onboard graphics card of the i7-1165G7 processor.
pciconf -lBceVv vgapci0 reports

vgapci0@pci0:0:2:0:	class=0x030000 rev=0x01 hdr=0x00 vendor=0x8086 device=0x9a49 subvendor=0x1e83 subdevice=0x3e35
    vendor     = 'Intel Corporation'
    device     = 'TigerLake-LP GT2 [Iris Xe Graphics]'
    class      = display
    subclass   = VGA
    cap 09[40] = vendor (length 12) Intel cap 0 version 1
    cap 10[70] = PCI-Express 2 root endpoint max data 128(128) FLR
                 max read 128
    cap 05[ac] = MSI supports 1 message, vector masks 
    cap 01[d0] = powerspec 2  supports D0 D3  current D0
    ecap 001b[100] = Process Address Space ID 1
    ecap 000f[200] = ATS 1
    ecap 0013[300] = Page Page Request 1
    ecap 0010[320] = SR-IOV 1 IOV disabled, Memory Space disabled, ARI disabled
                     0 VFs configured out of 7 supported
                     First VF RID Offset 0x0001, VF RID Stride 0x0001
                     VF Device ID 0x9a49
                     Page Sizes: 4096 (enabled), 8192, 65536, 262144, 1048576, 4194304
Comment 5 Peter Much 2022-09-22 22:56:46 UTC
Same Problem here, with a Fujitsu A3511 laptop.

This one has an i3-1115G4 processor, and I don't know if this is the same or a similar cause, but it's the same effect: machine does suspend, but instead of resuming it boots freshly when the power button is pressed.

This is reproduced with 12.3, with 13.1 and with 14-current as of this month.

It is reproduced no matter if we suspend with or without X running, or from single-user. 
It is reproduced no matter if we boot USB memstick or internal NVM disk.
It is reproduced also when disabling every possible hardware in BIOS.

With linux resume works. With linux it is enough to hit "Ctrl" (or any key) to resume.

More interesting: OpenBSD 7.1 also works! (I didn't get all devices back correctly, but I got a working shell prompt back for a beginning.)
Here the keyboard seems not to be scanned, as pressing "Ctrl" or any key does NOT resume. But pressing the power button does resume.

Any input on what I could try next is very much appreciated.
Comment 6 Peter Much 2022-09-24 11:24:30 UTC
Some more analysis:

When my machine starts, or on wakeup, it shortly rotates the fan. 
When I try to wakeup with FreeBSD, this happens. Then after a short time the power led goes out, and goes on again, and the fan is tested once again and the normal startup boot follows.

So, apparently the resume is done, but it fails, and then a normal reboot follows.

There is a file sys/amd64/acpica/acpi_wakecode.S
It is apparently one of the first things that should be run on wakeup.
I created an endless loop right at the beginning of that code.
This does not change the behaviour.

For verification I did the same in OpenBSD, and there it has the expected effect: on resume the power led goes on, and stays on, and nothing more happens.

So apparently our "wakecode" is not found, instead the thing hops to whereever to execute code, and then obviousely crashes.
Something must be wrong with the place where we put this code, or the way we tell the bios that place.
Here is the respective boot message:

acpi0: wakeup code va 0xfffffe001317f000 pa 0x9c000
Comment 7 Graham Perrin freebsd_committer freebsd_triage 2022-09-24 14:28:27 UTC
(In reply to Patrick Mackinlay from comment #4)

pkg query -x '%n %v' 'drm.*kmod'

What's listed?
Comment 8 Patrick Mackinlay 2022-09-24 17:55:36 UTC
(In reply to Graham Perrin from comment #7)

uname -a

FreeBSD grey 13.1-STABLE FreeBSD 13.1-STABLE #10 stable/13-n251117-8fc85536006: Thu Aug  4 11:05:05 UTC 2022     root@grey:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64

pkg query -x '%n %v' 'drm.*kmod'
drm-devel-kmod 5.7.19.g20220223


As far as I remember, at the time, the non devel drm module didn't work.

Note that suspend/resume fails even if I dont load any drm module.
Comment 9 Graham Perrin freebsd_committer freebsd_triage 2022-09-24 20:02:07 UTC
(In reply to Patrick Mackinlay from comment #8)

> drm-devel-kmod 5.7.19.g20220223

Please try graphics/drm-510-kmod instead. 

> … suspend/resume fails even if I dont load any drm module. …

That might be expected: bug 219953, bug 260994
Comment 10 Patrick Mackinlay 2022-09-24 23:56:12 UTC
(In reply to Graham Perrin from comment #9)

I upgraded to FreeBSD 13.1-RELEASE-p2 and installed drm-510-kmod 5.10.113_6 but I am afraid it still doesn't work
Comment 11 Graham Perrin freebsd_committer freebsd_triage 2022-09-25 04:28:53 UTC
(In reply to Patrick Mackinlay from comment #10)

Thanks, 

pkg info -x 'gpu-firmware-'

Is there a long list (if so: no need to paste), or nothing?
Comment 12 Patrick Mackinlay 2022-09-25 09:50:52 UTC
(In reply to Graham Perrin from comment #11)

At some point during the upgrade it did install a whole bunch of gpu-firmware-* packages, including

gpu-firmware-intel-kmod-tigerlake-20220511

/var/run/dmesg.boot reports

i915/tgl_dmc_ver2_08.bin: could not load firmware image, error 2
i915_tgl_dmc_ver2_08.bin: could not load firmware image, error 2
firmware: 'i915_tgl_dmc_ver2_08_bin' version 0: 18932 bytes loaded at 0xffffffff84293000
drmn0: successfully loaded firmware image 'i915/tgl_dmc_ver2_08.bin'
drmn0: [drm] Finished loading DMC firmware i915/tgl_dmc_ver2_08.bin (v2.8)
...
[drm] Initialized i915 1.6.0 20200917 for drmn0 on minor 0


I do also get a bunch of system message errors after using the laptop for a bit:

drmn0: [drm] *ERROR* Atomic update failure on pipe A (start=10447 end=10448) time 2142 us, min 1987, max 1999, scanline start 1946, end 43
drmn0: [drm] *ERROR* Atomic update failure on pipe A (start=13058 end=13059) time 1253 us, min 1987, max 1999, scanline start 1900, end 2002
drmn0: [drm] *ERROR* Atomic update failure on pipe A (start=15278 end=15279) time 1428 us, min 1987, max 1999, scanline start 1944, end 61
drmn0: [drm] *ERROR* Atomic update failure on pipe A (start=20888 end=20889) time 899 us, min 1987, max 1999, scanline start 1981, end 76
drmn0: [drm] *ERROR* Atomic update failure on pipe A (start=22988 end=22989) time 974 us, min 1987, max 1999, scanline start 1944, end 38
drmn0: [drm] *ERROR* Atomic update failure on pipe A (start=24818 end=24819) time 2019 us, min 1987, max 1999, scanline start 1900, end 2050
drmn0: [drm] *ERROR* Atomic update failure on pipe A (start=25208 end=25209) time 1251 us, min 1987, max 1999, scanline start 1881, end 2036
drmn0: [drm] *ERROR* Atomic update failure on pipe A (start=25358 end=25359) time 1455 us, min 1987, max 1999, scanline start 1884, end 2023
drmn0: [drm] *ERROR* Atomic update failure on pipe A (start=27458 end=27459) time 1372 us, min 1987, max 1999, scanline start 1879, end 2047
drmn0: [drm] *ERROR* Atomic update failure on pipe A (start=30518 end=30519) time 688 us, min 1987, max 1999, scanline start 1962, end 73
drmn0: [drm] *ERROR* Atomic update failure on pipe A (start=30968 end=30969) time 1276 us, min 1987, max 1999, scanline start 1857, end 2008
drmn0: [drm] *ERROR* Atomic update failure on pipe A (start=31028 end=31029) time 1605 us, min 1987, max 1999, scanline start 1835, end 2004
drmn0: [drm] *ERROR* Atomic update failure on pipe A (start=31508 end=31509) time 2099 us, min 1987, max 1999, scanline start 1921, end 24
Comment 13 Peter Much 2022-09-25 14:46:10 UTC
My installation got the packages from the public repo as of this week. They are:

drm-510-kmod 5.10.113_6
drm-kmod 20220907_1
gpu-firmware-kmod 20220511,1
gpu-firmware-*-kmod 20220511  // lots of them

When starting 'X' I can see these:

[drm] Unable to create a private tmpfs mount, hugepage support will be disabled(-19).
[drm] Got stolen memory base rx0, size 0x0
drmn0: successfully loaded firmware image 'i915/tgl_dmc_ver2_08.bin'
drmn0: [drm] Finished loading DMC firmware i915/tgl_dmc_ver2_08.bin (v2.8)
sysctl_warn_reuse: can't re-use a leaf (hw.dri.debug)!
[drm] Initialized i915 1.6.0 20200917 for drmn0 on minor 0
VT: Replacing driver "efifb" with new "fb".

When trying to suspend, the code in sys/contrib/dev/acpica/components/hardware/hwsleep.c:AcpiHwLegacySleep() is reached, and it suspends as soon as the SLP_EN bit is written to Pm1a/Pm1b (which does not happen with debug.acpi.suspend_bounce=1).

Not by any means was I able to get it back from there. According to https://uefi.org/htmlspecs/ACPI_Spec_6_4_html, chapter 16.3, the processor should then start from the Boot Vector and somehow arrive at the Waking Vector; which doesn't seem to be the case.

I might now blame the firmware, but, as far as I could see, OpenBSD does basically the same, and there it works.
Comment 14 Patrick Mackinlay 2022-09-26 21:48:11 UTC
Note that my arch linux install uses a newer firmware version:

tgl_dmc_ver2_12.bin
Comment 15 Peter Much 2022-10-07 01:32:26 UTC
I was now able to successfully resume my machine from suspend after doing:

# kldload tpm

So apparently this was the problem here.
Comment 16 Patrick Mackinlay 2022-10-08 21:10:29 UTC
(In reply to Peter Much from comment #15)

Loading the tpm module makes no difference on the MateBook X Pro 2021. It still fails to resume.
Comment 17 Graham Perrin freebsd_committer freebsd_triage 2022-10-09 06:31:41 UTC
(In reply to Peter Much from comment #15)

> # kldload tpm

Two days ago, feeling adventurous, I loaded the module on a relatively old computer where the module is almost certainly _not_ required. A computer that does normally sleep, and wake, without difficulty. 

If I'm not mistaken: loading tpm caused the subsequent suspend to fail (with a requirement to force off the computer). 

HP EliteBook 8570p
<https://support.hp.com/gb-en/document/c03393945>

Not seeking support. I'm just sharing the result of my foolishness.
Comment 18 Peter Much 2022-10-09 11:54:49 UTC
Graham, there was a security flaw in TPM 2.0: After a suspend/resume one was able to circumvent TPM; this is explained in one of the BsdCon videos.
To fix this flaw, TPM 2.0 does now not allow the computer to resume after a suspend, and forces a reset instead, unless it had been properly primed during the suspend.

Our TPM kmod does handle this. So, if the computer has a TPM 2.0 installed and running, one must kldload tpm, otherwise the resume cannot work.

It became obvious to me when working myself thru the changelog of OpenBSD, searching for something they do differently:
> Identified TPM2.0 devices and performed the 2.0-specific "suspend"
> command, allowing the lenovo xlr9 and xlnano using the latest BIOS
> (which added S3) to resume."

Additionally this hints to something else, too: there is some issue with the S3, which apparently has been deprecated by Intel for the Gen 11 processors, and was later re-added on public demand. But I don't know the details of this.
Comment 19 Patrick Mackinlay 2022-10-09 19:53:23 UTC
The MateBook X Pro 2021 does have a tpm 2 device, but I had that disabled in the BIOS. Loading the tpm kernel module does not fix the resume for me whether the tpm device is enabled or disabled in the BIOS.
Comment 20 huanghwh 2024-06-08 02:05:45 UTC
I have a MateBook X Pro 2023 with FreeBSD-14.1 RELEASE installed, got the same problem: when run :

acpiconf -s 3

the laptop appears to suspend fine, the screen tune to black, but it will not resume when press power button or press any key on keyboard.

I notice that the light on key "Caps" always is on when suspend it.

debug with: 

sysctl debug.acpi.suspend_bounce=1
acpiconf -s 3

works fine, except touch pad not working anymore

dmesg:

uhub1: at usbus1, port 1, addr 1 (disconnected)
ugen1.2: <Apple Inc. iPhone> at usbus1 (disconnected)
ipheth0: at uhub1, port 3, addr 1 (disconnected)
ipheth0: detached
ugen1.3: <3730304233343731345430 USB Camera> at usbus1 (disconnected)
uhub1: detached
uhub0: at usbus0, port 1, addr 1 (disconnected)
uhub0: detached
vgapci0: child drmn0 requested pci_set_powerstate
pci0: failed to set ACPI power state D3 on \134_SB_.PC00.GFX0: AE_BAD_PARAMETER
vgapci0: child drmn0 requested pci_set_powerstate
vgapci0: child drmn0 requested pci_enable_io
vgapci0: child drmn0 requested pci_enable_io
uhub0 on usbus0
uhub0: <Intel XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0
uhub1 on usbus1
uhub1: <Intel XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus1
uhub0: 5 ports with 5 removable, self powered
uhub1: 16 ports with 16 removable, self powered
ugen1.2: <Apple Inc. iPhone> at usbus1
ugen1.3: <3730304233343731345430 USB Camera> at usbus1
ipheth0 on uhub1
ipheth0: <Apple Inc. iPhone, class 0/0, rev 2.00/10.03, addr 1> on usbus1
ue0: <USB Ethernet> on ipheth0
ue0: Ethernet address: 3e:2e:f9:7e:cb:be



I tried building a minimal test kernel(zfs, rdr, nvme, nvd), The test kernel had the same issues.

I also tried to building 15.0-CURRENT, same issues.

# pkg info -x drm-61
drm-61-kmod-6.1.69_2

# pciconf -lv vgapci0
vgapci0@pci0:0:2:0:     class=0x030000 rev=0x04 hdr=0x00 vendor=0x8086 device=0xa7a0 subvendor=0x19e5 subdevice=0x3e6c
    vendor     = 'Intel Corporation'
    device     = 'Raptor Lake-P [Iris Xe Graphics]'
    class      = display
    subclass   = VGA