> Date: Fri, 23 May 2025 11:42:25 +0200 > From: Rafael Sadowski <raf...@sizeofvoid.org> > > On Fri May 23, 2025 at 11:38:28AM +0200, Rafael Sadowski wrote: > > On Wed May 21, 2025 at 01:02:46PM +0200, Mark Kettenis wrote: > > > > Date: Wed, 21 May 2025 11:36:47 +0200 > > > > From: Rafael Sadowski <raf...@sizeofvoid.org> > > > > > > > > On Sat May 10, 2025 at 10:03:21PM +0200, Mark Kettenis wrote: > > > > > > Date: Sun, 4 May 2025 19:20:38 +0200 > > > > > > From: Rafael Sadowski <raf...@sizeofvoid.org> > > > > > > > > > > > > On Wed Apr 23, 2025 at 11:36:41PM +0200, Mark Kettenis wrote: > > > > > > > > Date: Wed, 23 Apr 2025 14:16:14 +0200 > > > > > > > > From: Rafael Sadowski <raf...@sizeofvoid.org> > > > > > > > > > > > > > > > > Unfortunately, my new T14gen5 does not want to switch the > > > > > > > > suspend state. > > > > > > > > The red LED flashes quickly all the time but nothing happens. > > > > > > > > > > > > > > That may just mean the machine suspended but didn't reach the > > > > > > > deepest > > > > > > > sleep state. > > > > > > > > > > > > > > > Only a hard reset (hold the power button for 10 seconds) will > > > > > > > > help. > > > > > > > > > > > > > > That may just mean the methods you tried to wake it up didn't > > > > > > > work. > > > > > > > > > > > > > > > If there is something (patch/flag..) I can use to build the > > > > > > > > kernel or > > > > > > > > contribute some information I would be happy to do so. > > > > > > > > > > > > > > Please try what happens if you press the power button when the > > > > > > > machine > > > > > > > is up. The machine should do a clean shutdown. But if that > > > > > > > doesn't > > > > > > > happen the power button handling is borked and pressing it won't > > > > > > > wake > > > > > > > up the laptop from suspend. > > > > > > > > > > > > It looks like the power button under OpenBSD is broken. Nothing > > > > > > happens > > > > > > when I press the power button for 1,2,5 seconds. The fingerprint > > > > > > sensor > > > > > > is disabled. > > > > > > > > > > That's the point where you make sure I have acpidump(8) output for > > > > > this machine. > > > > > > > > > > > > > When I run zzz(1) with ddb.suspend=1 and I can see: > > > > > > > > xhci1: command ring abort timeout > > > > xhci2: command ring abort timeout > > > > > > > > Everything else printed with "detached". So i built an kernel with > > > > XHCI_DEBUG, dmesg see below. > > > > > > These messages aren't necessarily a problem. At least I expect the > > > machine would still resume (but maybe it would throw a few more errors.q > > > > > > What happens if you set the XHCI_NOCSS flag for these controllers in > > > dev/pci/xhci_pci.c? > > > > case PCI_VENDOR_AMD: > > - if (PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_AMD_17_1X_XHCI_1 > > || > > - PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_AMD_17_1X_XHCI_2) > > psc->sc.sc_flags |= XHCI_NOCSS; > > break; > > > > Unfortunately no luck. > > > > ... and here more with XHCI_DEBUG enabled (OCR'ed): > > xhci0: error clearing ep (1) > xhci0: xhci_cmd_slot_control > xhci_command_submit: tsleep() = 35 > cmd = 10 trb=0xfffffd813b67f0c0 (0x0000000000000000 0x00000000 > 0x2002801<CCYCLE>) > uhub4 detached > > xhci0: xhci_cmd_configure_ep dev 1 > xhci_command_submit: tsleep() = 35 > cmd = 12 trb=0xfffffd813b67f0d0 (0x000000013b705000 0x00000000 > 0x1003001<CCYCLE>) > > xhci0: error clearing ep (1) > xhci0: xhci_cmd_slot_control > xhci_command_submit: tsleep() = 35 > cmd = 10 trb=0xfffffd813b67f0e0 (0x0000000000000000 0x00000000 > 0x1002801<CCYCLE>) > ugen1 detached > > xhci0: xhci_cmd_configure_ep dev 3 > xhci_command_submit: tsleep() = 35 > cmd = 12 trb=0xfffffd813b67f000 (0x000000013b75f000 0x00000000 0x3003000) > > xhci0: error clearing ep (1) > xhci0: xhci_cmd_slot_control > xhci_command_submit: tsleep() = 35 > cmd = 10 trb=0xfffffd813b67f010 (0x0000000000000000 0x00000000 0x3002800) > uhub0 detached > video0 detached > uvideo0 detached > video1 detached > uvideo1 detached > ugen2 detached
Well, as I said, not necessarily a problem. I'll need to look into what's needed to make GPIOs work a wakeup interrupts. A quick glance at the code suggests that that probably won't work right now.
