From: Bjorn Helgaas <helgaas@kernel.org>
To: 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: Mon, 25 Sep 2023 08:48:41 -0500 [thread overview]
Message-ID: <20230925134841.GA382338@bhelgaas> (raw)
In-Reply-To: <20230925045928.GH3208943@black.fi.intel.com>
On Mon, Sep 25, 2023 at 07:59:28AM +0300, Mika Westerberg wrote:
> On Sun, Sep 24, 2023 at 03:18:00PM -0500, Bjorn Helgaas wrote:
> ...
> > So is there some user-level software that runs between the removal and
> > re-enumeration? Something that authorizes the 07:00.0 Upstream Port?
>
> No.
>
> They get "authorized" upon plug by boltd based on user decision and
> after that the firmware should keep them authorized as long as the
> device is connected, including also resume.
I'm trying to understand the events involved in bringing that link up.
When we resume, evidently the link is not up, and it doesn't come up
by itself no matter how long we wait. From the log at [1],
[ 0.494521] pci 0000:05:01.0: PCI bridge to [bus 07-3b]
The hierarchy that's a problem is bus 07-3b.
[ 117.485355] ACPI: PM: Preparing to enter system sleep state S3
Suspended.
[ 117.528216] ACPI: PM: Waking up from system sleep state S3
[ 117.606664] ACPI: EC: interrupt unblocked
[ 118.915870] thunderbolt 0000:06:00.0: control channel starting...
Resuming.
[ 118.985530] pcieport 0000:05:01.0: Data Link Layer Link Active not set in 1000 msec
[ 190.090902] pcieport 0000:05:01.0: pciehp: Slot(1): Card not present
[ 190.376024] pci_bus 0000:09: busn_res: [bus 09] is released
[ 190.376089] pci_bus 0000:0a: busn_res: [bus 0a] is released
[ 190.376168] pci_bus 0000:0b: busn_res: [bus 0b] is released
[ 190.376850] pci_bus 0000:0c: busn_res: [bus 0c] is released
[ 190.376883] pci_bus 0000:0d: busn_res: [bus 0d-3b] is released
[ 190.376912] pci_bus 0000:08: busn_res: [bus 08-3b] is released
Link from 05:01.0 didn't come up, so pciehp thinks the "slot" is empty
and we removed the problem hierarchy (bus 07-3b).
[ 191.754347] thunderbolt 0000:06:00.0: 1: DROM version: 1
[ 191.762638] thunderbolt 0-1: new device found, vendor=0x108 device=0x1630
[ 191.762641] thunderbolt 0-1: Lenovo ThinkPad Thunderbolt 3 Dock
[ 191.943506] pcieport 0000:05:01.0: pciehp: Slot(1): Card present
[ 191.943518] pcieport 0000:05:01.0: pciehp: Slot(1): Link Up
[ 192.074593] pci 0000:07:00.0: [8086:15d3] type 01 class 0x060400
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?
Does Windows suffer from the same 60+ second resume time on this
platform?
Bjorn
[1] https://bugzilla-attachments.redhat.com/attachment.cgi?id=1984803
next prev parent reply other threads:[~2023-09-25 13:48 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 [this message]
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=20230925134841.GA382338@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=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).