linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: Lukas Wunner <lukas@wunner.de>,
	Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: Kamil Paral <kparal@redhat.com>,
	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: Tue, 26 Sep 2023 12:55:30 -0500	[thread overview]
Message-ID: <20230926175530.GA418550@bhelgaas> (raw)
In-Reply-To: <20230925141930.GA21033@wunner.de>

On Mon, Sep 25, 2023 at 04:19:30PM +0200, Lukas Wunner wrote:
> On Mon, Sep 25, 2023 at 08:48:41AM -0500, Bjorn Helgaas wrote:
> > Now pciehp thinks the slot is occupied and the link is up, so we
> > re-enumerate the hierarchy.  Is this because thunderbolt did something
> > to 06:00.0 that made the link from 05:01.0 come up?
> 
> PCIe TLPs are encapsulated into Thunderbolt packets and transmitted
> alongside DisplayPort and other data over the same physical link.
> 
> For this to work, PCIe tunnels need to be set up between the Thunderbolt
> host controller and attached devices.  Once a tunnel is established,
> the PCIe link magically goes up and TLPs can be transmitted.
> 
> There are two ways to establish those tunnels:
> 
> 1/ By a firmware in the Thunderbolt host controller.
>    (firmware or "internal" connection manager, drivers/thunderbolt/icm.c)
> 
> 2/ Natively by the kernel.
>    (software connection manager)
> 
> I'm assuming that the laptop in question exclusively uses the firmware
> connection manager, hence the kernel is reliant on that firmware to
> establish tunnels and can't really do anything if it fails to do so.

Thanks for the background; that improves my meager understanding a
lot.

Since this seems to be a firmware issue, it does sound like this
laptop uses a firmware connection manager.  But there still seems to
be some kernel connection because pre-e8b908146d44, the link came up
in <5 seconds, and after the minor e8b908146d44 change, it takes >60
seconds.

I'm kind of at a loss here because I don't have a clear path forward.
What I'm hearing is that the real fix is a firmware update or a BIOS
setting change (Thunderbolt "user" instead of "secure" mode).

That is problematic for users, who will think resume got broken and
they don't know how to fix it.  It's problematic for me, because it
*looks* like a PCI issue and a PCI change exposed it, so I'll have to
deal with the reports.

Bjorn

  reply	other threads:[~2023-09-26 17:55 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
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 [this message]
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=20230926175530.GA418550@bhelgaas \
    --to=helgaas@kernel.org \
    --cc=bhelgaas@google.com \
    --cc=chris.chiu@canonical.com \
    --cc=kparal@redhat.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=lukas@wunner.de \
    --cc=mika.westerberg@linux.intel.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).