Re: [REGRESSION] resume with a Thunderbolt dock broke with commit e8b908146d44 "PCI/PM: Increase wait time after resume"

[Mika Westerberg <mika.westerberg@linux.intel.com>]

On Wed, Aug 23, 2023 at 04:02:06PM +0200, Kamil Paral wrote:
> On Wed, Aug 23, 2023 at 11:05 AM Mika Westerberg
> <mika.westerberg@linux.intel.com> 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

I think the correct setting for this is to have it disabled. This means
it is native PCIe with the runtime D3 support and looking at the ACPI
dump you shared this seems to be the case.

> 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.

I did not find anything "unusual" in the ACPI dump but I keep looking.

One thing I noticed, probably has nothing to do with this, but you have
the "security level" set to "secure". Now this is fine and actually
recommended but I wonder if anything changes if you switch that
temporarily to "user"? What is happening here is that once the system
enters S3 the Thunderbolt driver tells the firmware to save the
connected device list, and then once it exits S3 it is expected to
re-connect the PCIe tunnels of the devices on that list but this is not
happening and that's why the dock "dissappears" during resume.

In any case we can conclude that the commit in question has nothing to
do with the issue. This is completely Thunderbolt related problem.