On Thu, Aug 24, 2023 at 1:43 PM Mika Westerberg <mika.westerberg@xxxxxxxxxxxxxxx> wrote: > 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. That was a great suggestion. After switching to the user security level, the resume delay is gone, and my dock devices seem to be working almost immediately after resume! The dmesg for that is here: https://bugzilla-attachments.redhat.com/attachment.cgi?id=1985262 I've done tens of cycles and haven't found any race conditions, unlike with the TB assist mode. (Only once, my USB mouse wasn't working at all, but that's something that occasionally happens on most docks I've worked with and seems to be some different issue). I'm sorry I haven't found this earlier myself. I did try switching these options, but I bundled it together with enabling the TB assist mode, which has quirks, so I didn't realize switching just this one option might have an impact. > In any case we can conclude that the commit in question has nothing to > do with the issue. This is completely Thunderbolt related problem. Considering the information above, does this appear to be a solely dock-related issue (bugged firmware), or does it make sense to follow up on this in some different kernel list? I have to say I'm completely OK with running the laptop using the "user" TB security level, but if you think I should follow up somewhere to get the "secure" level fixed (or some workaround applied, etc), I can. Thanks a lot for all your help debugging this, Mika and Bjorn.
