On Wed, Aug 23, 2023 at 11:05 AM Mika Westerberg <mika.westerberg@xxxxxxxxxxxxxxx> wrote: > OK. Did you change any BIOS settings from the defaults that might have > affect on this? Sometimes these are exposed to through the BIOS menu and > the user can change those (Lenovo typically does not, expose them > though). These BIOS pages seem they could be relevant: https://imgur.com/a/vEltxpj And heureka, "Thunderbolt BIOS Assist Mode" affects this! It was disabled (not sure if that's the default or I changed it before). After I enable it, the resume 60+ second delay is gone, it resumes in standard ~5 seconds. The dock devices (mouse, LAN) still take a few extra seconds to activate. The dmesg for a resume with TB assist mode is here: https://bugzilla-attachments.redhat.com/attachment.cgi?id=1984785 Unfortunately, it seems to have its own quirks. There seems to be something like ~20% chance that the dock devices are no longer available after resume. I see the dock as connected in boltctl, but I no longer see the devices in lsusb. Reconnecting the dock doesn't help, more suspend&resume cycles don't help, only system reboot helps. I captured this situation in this dmesg (there are multiple resume events, the devices disappear after the last one): https://bugzilla-attachments.redhat.com/attachment.cgi?id=1984786 This might be the same problem that I described regarding pcie_aspm=off to Bjorn, but I'd need to check. Either way, this wasn't happening when the TB assist mode was disabled. > Can you also attach output of acpidump to and dmesg with > "thunderbolt.dyndbg=+p" in the command line? acpidump: https://bugzilla-attachments.redhat.com/attachment.cgi?id=1984802 dmesg with "thunderbolt.dyndbg=+p" and one suspend&resume cycle: https://bugzilla-attachments.redhat.com/attachment.cgi?id=1984803 I'm currently running kernel 6.4.8 packaged in Fedora 38 for these experiments, I hope that's OK. If needed, I can switch to the latest kernel.
