Re: Lenovo ThinkCentre M910q fails to suspend
On Fri, Jun 17, 2022 at 12:46:49PM -0700, Mike Larkin wrote: > Sorry, out of ideas. No worries. Thanks for all of the back and forth :) -- Best Regards Edd Barrett https://www.theunixzoo.co.uk
Re: Lenovo ThinkCentre M910q fails to suspend
On Fri, Jun 17, 2022 at 08:32:29PM +0100, Edd Barrett wrote: > Hi Mike, > > On Fri, Jun 17, 2022 at 11:55:51AM -0700, Mike Larkin wrote: > > > - disabling xhci in ukc: the system fails to boot multi-user. The first > > >oddness comes where cpus #1-3 fail to "become ready" (as reported by > > > dmesg). > > >It spends a while thinking about these cores not coming up, before > > >eventually proceeding, but eventually hard resetting. I guess the > > > system > > >really needs xhci to function then... > > > > That really makes no sense. can you try the same experiment again using > > GENERIC? > > Doing `boot bsd.sp -c` and then `disable xhci` means that the system can at > least boot with no xhci, but sadly it still won't stay in the suspended state. > > That might rule out xhci as a source of the issue, maybe. > > -- > Best Regards > Edd Barrett > > https://www.theunixzoo.co.uk Sorry, out of ideas.
Re: Lenovo ThinkCentre M910q fails to suspend
Hi Mike, On Fri, Jun 17, 2022 at 11:55:51AM -0700, Mike Larkin wrote: > > - disabling xhci in ukc: the system fails to boot multi-user. The first > >oddness comes where cpus #1-3 fail to "become ready" (as reported by > > dmesg). > >It spends a while thinking about these cores not coming up, before > >eventually proceeding, but eventually hard resetting. I guess the system > >really needs xhci to function then... > > That really makes no sense. can you try the same experiment again using > GENERIC? Doing `boot bsd.sp -c` and then `disable xhci` means that the system can at least boot with no xhci, but sadly it still won't stay in the suspended state. That might rule out xhci as a source of the issue, maybe. -- Best Regards Edd Barrett https://www.theunixzoo.co.uk
Re: Lenovo ThinkCentre M910q fails to suspend
On Fri, Jun 17, 2022 at 06:41:23PM +0100, Edd Barrett wrote: > Hi Mike, > > On Fri, Jun 17, 2022 at 10:20:35AM -0700, Mike Larkin wrote: > > Oh, didn't read this closely enough the first time. If ZZZ doesn't > > instantly wake > > the machine, then it's one of the two S3 devices described in your next > > email. > > Since one is XHCI, I'd disable xhci in ukc and see if that helps. Or maybe > > the > > other *hci(4)s also. > > Alright, so here's some more info. > > - disabling xhci in ukc: the system fails to boot multi-user. The first >oddness comes where cpus #1-3 fail to "become ready" (as reported by > dmesg). >It spends a while thinking about these cores not coming up, before >eventually proceeding, but eventually hard resetting. I guess the system >really needs xhci to function then... That really makes no sense. can you try the same experiment again using GENERIC? > > - disabling ehci or ahci: no change to sleep behaviour. > > - disabling usb: no change to sleep behaviour. > > I don't see any [XEA]HCI options in the BIOS that I could tweak. > > Unless you have any other ideas, I'll try disabling random devices in the hope > that I can narrow it down... I've already tried the network card, it aint > that. > > Thanks. > > -- > Best Regards > Edd Barrett > > https://www.theunixzoo.co.uk >
Re: Lenovo ThinkCentre M910q fails to suspend
Hi Mike, On Fri, Jun 17, 2022 at 10:20:35AM -0700, Mike Larkin wrote: > Oh, didn't read this closely enough the first time. If ZZZ doesn't instantly > wake > the machine, then it's one of the two S3 devices described in your next email. > Since one is XHCI, I'd disable xhci in ukc and see if that helps. Or maybe the > other *hci(4)s also. Alright, so here's some more info. - disabling xhci in ukc: the system fails to boot multi-user. The first oddness comes where cpus #1-3 fail to "become ready" (as reported by dmesg). It spends a while thinking about these cores not coming up, before eventually proceeding, but eventually hard resetting. I guess the system really needs xhci to function then... - disabling ehci or ahci: no change to sleep behaviour. - disabling usb: no change to sleep behaviour. I don't see any [XEA]HCI options in the BIOS that I could tweak. Unless you have any other ideas, I'll try disabling random devices in the hope that I can narrow it down... I've already tried the network card, it aint that. Thanks. -- Best Regards Edd Barrett https://www.theunixzoo.co.uk
Re: Lenovo ThinkCentre M910q fails to suspend
On Fri, Jun 17, 2022 at 09:14:45AM +0100, Edd Barrett wrote: > Hi Mike, > > On Thu, Jun 16, 2022 at 09:19:50PM -0700, Mike Larkin wrote: > > From your original dmesg: > > > > > acpi0: wakeup devices PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) > > > PEGP(S4) SIO1(S3) RP09(S4) PXSX(S4) RP10(S4) PXSX(S4) RP11(S4) PXSX(S4) > > > RP12(S4) PXSX(S4) RP13(S4) [...] > > > > Notice the [...] at the end, this is printed after 16 devices. What I'd > > suggest > > is this: > > > > 1. remove the code that truncates this list after 16, and note down all the > > wake > > devices. > > > > 2. If there are any in S3, try using ZZZ instead of zzz. If the machine > > does not instantly > > wake, it's possible it's because of one of those S3 devices doing the wake > > (since ZZZ > > uses S4). > > I'll try removing the truncation then. Bear with me. > > In the meantime, notice that the truncated list does include one S3 item > `SIO1(S3)`. I don't know if that's what we are looking for? > > FWIW, I have already tried `ZZZ` on this machine and it does succeed to > hibernate, but upon wake up, it hangs when decompressing the memory image. I > left it decompressing a ~50MB image for more than an hour and concluded it had > got stuck. Oh, didn't read this closely enough the first time. If ZZZ doesn't instantly wake the machine, then it's one of the two S3 devices described in your next email. Since one is XHCI, I'd disable xhci in ukc and see if that helps. Or maybe the other *hci(4)s also. Now, why ZZZ fails to unpack is some other problem but the instant wake is not related to that. -ml > > > 3. If everything is S4, well, you're going to have to trace down those > > short names > > like PEGP, PXSX, etc, and disable one at a time until you find the one that > > is > > doing the wake. And it's possible it's none of these and is a fixed function > > button or something. > > One additional piece of info, which may be worthless. I tried a Debian live > USB > stick, to see if Linux was able to sleep this box. It was able to. > > I don't know if that rules out the idea of a fixed-function button? > > -- > Best Regards > Edd Barrett > > https://www.theunixzoo.co.uk
Re: Lenovo ThinkCentre M910q fails to suspend
On Fri, Jun 17, 2022 at 09:14:45AM +0100, Edd Barrett wrote: > Hi Mike, > > On Thu, Jun 16, 2022 at 09:19:50PM -0700, Mike Larkin wrote: > > From your original dmesg: > > > > > acpi0: wakeup devices PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) > > > PEGP(S4) SIO1(S3) RP09(S4) PXSX(S4) RP10(S4) PXSX(S4) RP11(S4) PXSX(S4) > > > RP12(S4) PXSX(S4) RP13(S4) [...] > > > > Notice the [...] at the end, this is printed after 16 devices. What I'd > > suggest > > is this: > > > > 1. remove the code that truncates this list after 16, and note down all the > > wake > > devices. > > > > 2. If there are any in S3, try using ZZZ instead of zzz. If the machine > > does not instantly > > wake, it's possible it's because of one of those S3 devices doing the wake > > (since ZZZ > > uses S4). > > I'll try removing the truncation then. Bear with me. > > In the meantime, notice that the truncated list does include one S3 item > `SIO1(S3)`. I don't know if that's what we are looking for? > > FWIW, I have already tried `ZZZ` on this machine and it does succeed to > hibernate, but upon wake up, it hangs when decompressing the memory image. I > left it decompressing a ~50MB image for more than an hour and concluded it had > got stuck. > > > 3. If everything is S4, well, you're going to have to trace down those > > short names > > like PEGP, PXSX, etc, and disable one at a time until you find the one that > > is > > doing the wake. And it's possible it's none of these and is a fixed function > > button or something. > > One additional piece of info, which may be worthless. I tried a Debian live > USB > stick, to see if Linux was able to sleep this box. It was able to. > > I don't know if that rules out the idea of a fixed-function button? > > -- > Best Regards > Edd Barrett > > https://www.theunixzoo.co.uk You're going to have to play trial and error then disabling devices until you find the one that hangs. Without the hardware in front of me, that's the best advice I can offer. Sorry. -ml
Re: Lenovo ThinkCentre M910q fails to suspend
On Fri, Jun 17, 2022 at 09:14:45AM +0100, Edd Barrett wrote: > > 1. remove the code that truncates this list after 16, and note down all the > > wake devices. Here's the full list: acpi0: wakeup devices PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) PEGP(S4) SIO1(S3) RP09(S4) PXSX(S4) RP10(S4) PXSX(S4) RP11(S4) PXSX(S4) RP12(S4) PXSX(S4) RP13(S4) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4) RP06(S4) PXSX(S4) RP07(S4) PXSX(S4) RP08(S4) PXSX(S4) RP17(S4) PXSX(S4) RP18(S4) PXSX(S4) RP19(S4) PXSX(S4) RP20(S4) PXSX(S4) RP21(S4) PXSX(S4) RP22(S4) PXSX(S4) RP23(S4) PXSX(S4) RP24(S4) PXSX(S4) RP14(S4) PXSX(S4) RP15(S4) PXSX(S4) RP16(S4) PXSX(S4) GLAN(S4) XHC_(S3) XDCI(S4) HDAS(S4) So there are just two S3 things listed: - SIO1(S3) - XHC_(S3) -- Best Regards Edd Barrett https://www.theunixzoo.co.uk
Re: Lenovo ThinkCentre M910q fails to suspend
Hi Mike, On Thu, Jun 16, 2022 at 09:19:50PM -0700, Mike Larkin wrote: > From your original dmesg: > > > acpi0: wakeup devices PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) PEGP(S4) > > SIO1(S3) RP09(S4) PXSX(S4) RP10(S4) PXSX(S4) RP11(S4) PXSX(S4) RP12(S4) > > PXSX(S4) RP13(S4) [...] > > Notice the [...] at the end, this is printed after 16 devices. What I'd > suggest > is this: > > 1. remove the code that truncates this list after 16, and note down all the > wake > devices. > > 2. If there are any in S3, try using ZZZ instead of zzz. If the machine does > not instantly > wake, it's possible it's because of one of those S3 devices doing the wake > (since ZZZ > uses S4). I'll try removing the truncation then. Bear with me. In the meantime, notice that the truncated list does include one S3 item `SIO1(S3)`. I don't know if that's what we are looking for? FWIW, I have already tried `ZZZ` on this machine and it does succeed to hibernate, but upon wake up, it hangs when decompressing the memory image. I left it decompressing a ~50MB image for more than an hour and concluded it had got stuck. > 3. If everything is S4, well, you're going to have to trace down those short > names > like PEGP, PXSX, etc, and disable one at a time until you find the one that is > doing the wake. And it's possible it's none of these and is a fixed function > button or something. One additional piece of info, which may be worthless. I tried a Debian live USB stick, to see if Linux was able to sleep this box. It was able to. I don't know if that rules out the idea of a fixed-function button? -- Best Regards Edd Barrett https://www.theunixzoo.co.uk
Re: Lenovo ThinkCentre M910q fails to suspend
On Thu, Jun 16, 2022 at 08:48:36PM +0100, Edd Barrett wrote: > On Thu, Jun 16, 2022 at 10:22:16AM -0700, Mike Larkin wrote: > > did it ever work in the past? > > I've only just received the machine, so it's difficult to say. > > I've spent the last hour changing various BIOS settings to see if anything > changes, but alas no. I don't see any sleep-related power options, and any > fancy power stuff I don't need or recognise, I've disabled. No joy. > > I've even updated the BIOS software to no avail. Hrm... > > -- > Best Regards > Edd Barrett > > https://www.theunixzoo.co.uk >From your original dmesg: > acpi0: wakeup devices PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) PEGP(S4) > SIO1(S3) RP09(S4) PXSX(S4) RP10(S4) PXSX(S4) RP11(S4) PXSX(S4) RP12(S4) > PXSX(S4) RP13(S4) [...] Notice the [...] at the end, this is printed after 16 devices. What I'd suggest is this: 1. remove the code that truncates this list after 16, and note down all the wake devices. 2. If there are any in S3, try using ZZZ instead of zzz. If the machine does not instantly wake, it's possible it's because of one of those S3 devices doing the wake (since ZZZ uses S4). 3. If everything is S4, well, you're going to have to trace down those short names like PEGP, PXSX, etc, and disable one at a time until you find the one that is doing the wake. And it's possible it's none of these and is a fixed function button or something. good luck -ml
Re: Lenovo ThinkCentre M910q fails to suspend
On Thu, Jun 16, 2022 at 10:22:16AM -0700, Mike Larkin wrote: > did it ever work in the past? I've only just received the machine, so it's difficult to say. I've spent the last hour changing various BIOS settings to see if anything changes, but alas no. I don't see any sleep-related power options, and any fancy power stuff I don't need or recognise, I've disabled. No joy. I've even updated the BIOS software to no avail. Hrm... -- Best Regards Edd Barrett https://www.theunixzoo.co.uk
Re: Lenovo ThinkCentre M910q fails to suspend
On Thu, Jun 16, 2022 at 05:14:53PM +0100, Edd Barrett wrote: > Hi, > > Has anyone managed to get a Lenovo ThinkCentre M910q (or similar) to suspend > with OpenBSD? > > When invoking `zzz` the system prepares to go down, the screen goes blank, but > then a short while later, the system comes back, as though it was awoken > straight away. did it ever work in the past? > > Here's the diff between the initial dmesg and the dmesg after this "suspend > and > come back" described above: > > ``` > --- dmesg Thu Jun 16 16:53:44 2022 > +++ dmesg.1 Thu Jun 16 16:55:31 2022 > @@ -360,3 +360,22 @@ > inteldrm0: 1920x1080, 32bpp > wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation), using wskbd0 > wsdisplay0: screen 1-5 added (std, vt100 emulation) > +uhub0 detached > +uhub0 at usb0 configuration 1 interface 0 "Intel xHCI root hub" rev > 3.00/1.00 addr 1 > +drm:pid42656:intel_ddi_sanitize_encoder_pll_mapping *NOTICE* [drm] > [ENCODER:94:DDI J/PHY @] is disabled/in DSI mode with an ungated DDI clock, > gate it > +drm:pid42656:intel_ddi_sanitize_encoder_pll_mapping *NOTICE* [drm] > [ENCODER:109:DDI J/PHY @] is disabled/in DSI mode with an ungated DDI clock, > gate it > +drm:pid42656:intel_ddi_sanitize_encoder_pll_mapping *NOTICE* [drm] > [ENCODER:119:DDI J/PHY @] is disabled/in DSI mode with an ungated DDI clock, > gate it > +uhidev0 at uhub0 port 11 configuration 1 interface 0 "SINO WEALTH Gaming KB" > rev 2.00/1.03 addr 2 > +uhidev0: iclass 3/1 > +ukbd0 at uhidev0: 8 variable keys, 6 key codes > +wskbd1 at ukbd0 mux 1 > +wskbd1: connecting to wsdisplay0 > +uhidev1 at uhub0 port 11 configuration 1 interface 1 "SINO WEALTH Gaming KB" > rev 2.00/1.03 addr 2 > +uhidev1: iclass 3/0, 5 report ids > +ukbd1 at uhidev1 reportid 1: 120 variable keys, 0 key codes > +wskbd2 at ukbd1 mux 1 > +wskbd2: connecting to wsdisplay0 > +ucc0 at uhidev1 reportid 2: 573 usages, 18 keys, array > +wskbd3 at ucc0 mux 1 > +wskbd3: connecting to wsdisplay0 > +uhid0 at uhidev1 reportid 5: input=0, output=0, feature=5 > ``` > > Is it odd that devices come back which we never saw detach? > > Repeating the same again, but with the inteldrm driver disabled, in case those > scary messages have something to do with this: > > ``` > --- dmesg Thu Jun 16 17:04:43 2022 > +++ dmesg.1 Thu Jun 16 17:05:01 2022 > @@ -554,3 +554,19 @@ > softraid0 at root > scsibus4 at softraid0: 256 targets > root on sd0a (5d59e5562a788986.a) swap on sd0b dump on sd0b > +wskbd1: disconnecting from wsdisplay0 > +wskbd1 detached > +ukbd0 detached > +uhidev0 detached > +wskbd2: disconnecting from wsdisplay0 > +wskbd2 detached > +ukbd1 detached > +wskbd3: disconnecting from wsdisplay0 > +wskbd3 detached > +ucc0 detached > +uhid0 detached > +uhidev1 detached > +uhub0 detached > +uhub0 at usb0 configuration 1 interface 0 "Intel xHCI root hub" rev > 3.00/1.00 addr 1 > +uhub0: port 11, set config 0 at addr 2 failed > +uhub0: device problem, disabling port 11 > ``` > > This time we see more devices detach, but when uhub0 comes back there is a > problem. curious... > > Does anyone have any idea what is going on here? This was due to be my new > porting box, but I need it to suspend... > > (FWIW: the system also fails to come up from ZZZ hibernate, but one thing at a > time) > > Full dmesg (with inteldrm): > > ``` > OpenBSD 7.1-current (GENERIC.MP) #582: Mon Jun 13 15:37:01 MDT 2022 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 17044692992 (16255MB) > avail mem = 16510771200 (15745MB) > random: good seed from bootblocks > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xdcd91000 (88 entries) > bios0: vendor LENOVO version "M1AKT39A" date 07/16/2018 > bios0: LENOVO 10MUS2UG00 > acpi0 at bios0: ACPI 6.1 > acpi0: sleep states S0 S3 S4 S5 > acpi0: tables DSDT FACP APIC FPDT MCFG SSDT FIDT SLIC MSDM SSDT SSDT HPET > SSDT UEFI SSDT LPIT WSMT SSDT SSDT DBGP DBG2 DMAR TPM2 LUFT ASF! BGRT > acpi0: wakeup devices PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) PEGP(S4) > SIO1(S3) RP09(S4) PXSX(S4) RP10(S4) PXSX(S4) RP11(S4) PXSX(S4) RP12(S4) > PXSX(S4) RP13(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-6500T CPU @ 2.50GHz, 2394.42 MHz, 06-5e-03 > 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,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN > cpu0: 256KB 64b/line 8-way L2 cache > cpu0: smt 0, core 0, pac
Lenovo ThinkCentre M910q fails to suspend
Hi, Has anyone managed to get a Lenovo ThinkCentre M910q (or similar) to suspend with OpenBSD? When invoking `zzz` the system prepares to go down, the screen goes blank, but then a short while later, the system comes back, as though it was awoken straight away. Here's the diff between the initial dmesg and the dmesg after this "suspend and come back" described above: ``` --- dmesg Thu Jun 16 16:53:44 2022 +++ dmesg.1 Thu Jun 16 16:55:31 2022 @@ -360,3 +360,22 @@ inteldrm0: 1920x1080, 32bpp wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation), using wskbd0 wsdisplay0: screen 1-5 added (std, vt100 emulation) +uhub0 detached +uhub0 at usb0 configuration 1 interface 0 "Intel xHCI root hub" rev 3.00/1.00 addr 1 +drm:pid42656:intel_ddi_sanitize_encoder_pll_mapping *NOTICE* [drm] [ENCODER:94:DDI J/PHY @] is disabled/in DSI mode with an ungated DDI clock, gate it +drm:pid42656:intel_ddi_sanitize_encoder_pll_mapping *NOTICE* [drm] [ENCODER:109:DDI J/PHY @] is disabled/in DSI mode with an ungated DDI clock, gate it +drm:pid42656:intel_ddi_sanitize_encoder_pll_mapping *NOTICE* [drm] [ENCODER:119:DDI J/PHY @] is disabled/in DSI mode with an ungated DDI clock, gate it +uhidev0 at uhub0 port 11 configuration 1 interface 0 "SINO WEALTH Gaming KB" rev 2.00/1.03 addr 2 +uhidev0: iclass 3/1 +ukbd0 at uhidev0: 8 variable keys, 6 key codes +wskbd1 at ukbd0 mux 1 +wskbd1: connecting to wsdisplay0 +uhidev1 at uhub0 port 11 configuration 1 interface 1 "SINO WEALTH Gaming KB" rev 2.00/1.03 addr 2 +uhidev1: iclass 3/0, 5 report ids +ukbd1 at uhidev1 reportid 1: 120 variable keys, 0 key codes +wskbd2 at ukbd1 mux 1 +wskbd2: connecting to wsdisplay0 +ucc0 at uhidev1 reportid 2: 573 usages, 18 keys, array +wskbd3 at ucc0 mux 1 +wskbd3: connecting to wsdisplay0 +uhid0 at uhidev1 reportid 5: input=0, output=0, feature=5 ``` Is it odd that devices come back which we never saw detach? Repeating the same again, but with the inteldrm driver disabled, in case those scary messages have something to do with this: ``` --- dmesg Thu Jun 16 17:04:43 2022 +++ dmesg.1 Thu Jun 16 17:05:01 2022 @@ -554,3 +554,19 @@ softraid0 at root scsibus4 at softraid0: 256 targets root on sd0a (5d59e5562a788986.a) swap on sd0b dump on sd0b +wskbd1: disconnecting from wsdisplay0 +wskbd1 detached +ukbd0 detached +uhidev0 detached +wskbd2: disconnecting from wsdisplay0 +wskbd2 detached +ukbd1 detached +wskbd3: disconnecting from wsdisplay0 +wskbd3 detached +ucc0 detached +uhid0 detached +uhidev1 detached +uhub0 detached +uhub0 at usb0 configuration 1 interface 0 "Intel xHCI root hub" rev 3.00/1.00 addr 1 +uhub0: port 11, set config 0 at addr 2 failed +uhub0: device problem, disabling port 11 ``` This time we see more devices detach, but when uhub0 comes back there is a problem. curious... Does anyone have any idea what is going on here? This was due to be my new porting box, but I need it to suspend... (FWIW: the system also fails to come up from ZZZ hibernate, but one thing at a time) Full dmesg (with inteldrm): ``` OpenBSD 7.1-current (GENERIC.MP) #582: Mon Jun 13 15:37:01 MDT 2022 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 17044692992 (16255MB) avail mem = 16510771200 (15745MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xdcd91000 (88 entries) bios0: vendor LENOVO version "M1AKT39A" date 07/16/2018 bios0: LENOVO 10MUS2UG00 acpi0 at bios0: ACPI 6.1 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT MCFG SSDT FIDT SLIC MSDM SSDT SSDT HPET SSDT UEFI SSDT LPIT WSMT SSDT SSDT DBGP DBG2 DMAR TPM2 LUFT ASF! BGRT acpi0: wakeup devices PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) PEGP(S4) SIO1(S3) RP09(S4) PXSX(S4) RP10(S4) PXSX(S4) RP11(S4) PXSX(S4) RP12(S4) PXSX(S4) RP13(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-6500T CPU @ 2.50GHz, 2394.42 MHz, 06-5e-03 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,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 24MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i5-6500T CPU @ 2.50GHz, 2394.43 MHz, 06-5e-03 cpu1: FPU,VME,DE,PSE,TSC,MSR,PA
