From: Mika Westerberg <mika.westerberg@linux.intel.com>
To: Kamil Paral <kparal@redhat.com>
Cc: linux-pci@vger.kernel.org, regressions@lists.linux.dev,
bhelgaas@google.com, chris.chiu@canonical.com
Subject: Re: [REGRESSION] resume with a Thunderbolt dock broke with commit e8b908146d44 "PCI/PM: Increase wait time after resume"
Date: Fri, 25 Aug 2023 12:46:46 +0300 [thread overview]
Message-ID: <20230825094646.GC3465@black.fi.intel.com> (raw)
In-Reply-To: <CA+cBOTej22hWEFvMOnFfKy16tuzS_+S7kccPPYXNoGVbYMoEdA@mail.gmail.com>
Hi,
On Fri, Aug 25, 2023 at 10:42:55AM +0200, Kamil Paral wrote:
> On Thu, Aug 24, 2023 at 1:43 PM Mika Westerberg
> <mika.westerberg@linux.intel.com> 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
Yeah looks good now.
> 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.
I would start by contacting Lenovo because I suspect this is Thunderbolt
firmware (host side not dock) issue so they may pull a newer one for
this one from Intel.
next prev parent reply other threads:[~2023-08-25 9:47 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-21 10:39 [REGRESSION] resume with a Thunderbolt dock broke with commit e8b908146d44 "PCI/PM: Increase wait time after resume" Kamil Paral
2023-08-21 13:12 ` Mika Westerberg
2023-08-22 16:43 ` Kamil Paral
2023-08-23 5:07 ` Mika Westerberg
2023-08-23 7:00 ` Kamil Paral
2023-08-23 7:44 ` Mika Westerberg
2023-08-23 7:56 ` Mika Westerberg
2023-08-23 8:20 ` Kamil Paral
2023-08-23 9:05 ` Mika Westerberg
2023-08-23 14:02 ` Kamil Paral
2023-08-24 11:43 ` Mika Westerberg
2023-08-25 8:42 ` Kamil Paral
2023-08-25 9:46 ` Mika Westerberg [this message]
2023-08-25 11:42 ` Kamil Paral
2023-09-23 22:46 ` Bjorn Helgaas
2023-09-24 13:27 ` Mika Westerberg
2023-09-24 20:18 ` Bjorn Helgaas
2023-09-25 4:59 ` Mika Westerberg
2023-09-25 13:48 ` Bjorn Helgaas
2023-09-25 14:19 ` Lukas Wunner
2023-09-26 17:55 ` Bjorn Helgaas
2023-09-27 5:16 ` Mika Westerberg
2023-09-27 11:57 ` Bjorn Helgaas
2023-09-27 12:47 ` Mika Westerberg
2023-09-27 14:31 ` Lukas Wunner
2023-09-27 14:42 ` Mika Westerberg
2023-09-27 15:36 ` Mika Westerberg
2023-09-27 16:50 ` Bjorn Helgaas
2023-09-27 17:01 ` Mika Westerberg
2023-09-27 17:24 ` Bjorn Helgaas
2023-09-27 18:02 ` Mika Westerberg
2023-09-27 19:41 ` Bjorn Helgaas
2023-09-28 4:42 ` Mika Westerberg
2023-09-28 15:49 ` Bjorn Helgaas
2023-10-05 13:01 ` Kamil Paral
2023-10-05 19:00 ` Bjorn Helgaas
[not found] ` <CA+cBOTds9k1Q2haC_gTpsUvjP02dHOv9vSconFEAu-Fsxwf36A@mail.gmail.com>
2023-09-27 13:53 ` Mika Westerberg
2023-09-27 14:12 ` Kamil Paral
2023-10-05 12:54 ` Kamil Paral
2023-10-05 13:09 ` Mika Westerberg
2023-09-27 14:08 ` Kamil Paral
2023-08-21 19:10 ` Bjorn Helgaas
2023-08-22 16:36 ` Kamil Paral
2023-11-01 10:59 ` Linux regression tracking (Thorsten Leemhuis)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230825094646.GC3465@black.fi.intel.com \
--to=mika.westerberg@linux.intel.com \
--cc=bhelgaas@google.com \
--cc=chris.chiu@canonical.com \
--cc=kparal@redhat.com \
--cc=linux-pci@vger.kernel.org \
--cc=regressions@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.