From: Mika Westerberg <mika.westerberg@linux.intel.com>
To: Kenneth Crudup <kenny@panix.com>
Cc: linux-usb@vger.kernel.org
Subject: Re: So, I had to revert d6d458d42e1 ("Handle DisplayPort tunnel activation asynchronously") too, to stop my resume crashes
Date: Tue, 4 Mar 2025 10:27:31 +0200 [thread overview]
Message-ID: <20250304082731.GF3713119@black.fi.intel.com> (raw)
In-Reply-To: <48ef4c14-55d5-4baa-b862-f9e7368ed950@panix.com>
On Mon, Mar 03, 2025 at 11:44:13AM -0800, Kenneth Crudup wrote:
>
> On 3/3/25 10:20, Kenneth Crudup wrote:
>
> > Building now. Fingers crossed!
>
> So far, so good- tried a variety of suspend/hibernate with/without scenarios
> on none, one and two connected monitors, and I can't get any resume OOPSes.
> Nice!
Okay cool, let me know any findings.
> I did see one anomaly I haven't seen before, but I'm not sure if it's
> related to this patch (or original commit, masked by the OOPS) or not. For
> some reason after resuming from the 2nd or 3rd hibernation cycle my Belkin
> Dock couldn't get authorized by boltd after I'd plugged it in
> post-hibernation-resume. It was indeed authorized the first time
> (post-hibernate) with the new code (was plugged in at the time of resume):
>
> ----
> 2025-03-03T10:39:34.405568-08:00 xps-9320 boltd[1240]:
> [c2010000-0072-Thunderbolt 3 Dock Core ] parent is 63ae8780-500c...
> 2025-03-03T10:39:34.406815-08:00 xps-9320 boltd[1240]:
> [c2010000-0072-Thunderbolt 3 Dock Core ] connected: connected
> (/sys/devices/pci0000:00/0000:00:0d.2/domain0/0-0/0-1)
> 2025-03-03T10:39:34.406995-08:00 xps-9320 boltd[1240]:
> [c2010000-0072-Thunderbolt 3 Dock Core ] auto-auth: authmode: enabled,
> policy: iommu, iommu: yes -> ok
> 2025-03-03T10:39:34.407094-08:00 xps-9320 boltd[1240]:
> [c2010000-0072-Thunderbolt 3 Dock Core ] auto-auth: security: iommu+user
> mode, key: no -> ok
> 2025-03-03T10:39:34.407287-08:00 xps-9320 boltd[1240]:
> [c2010000-0072-Thunderbolt 3 Dock Core ] authorize: authorization
> prepared for 'user' level
> 2025-03-03T10:39:34.408876-08:00 xps-9320 boltd[1240]:
> [c2010000-0072-Thunderbolt 3 Dock Core ] udev: device changed:
> authorizing -> authorizing
> 2025-03-03T10:39:34.412223-08:00 xps-9320 boltd[1240]:
> [c2010000-0072-Thunderbolt 3 Dock Core ] udev: device changed:
> authorizing -> authorizing
> 2025-03-03T10:39:34.417191-08:00 xps-9320 boltd[1240]:
> [c2010000-0072-Thunderbolt 3 Dock Core ] authorize: finished: ok (status:
> authorized, flags: 0)
> 2025-03-03T10:39:34.417414-08:00 xps-9320 boltd[1240]:
> [c2010000-0072-Thunderbolt 3 Dock Core ] auto-auth: authorization
> successful
> 2025-03-03T10:39:34.419207-08:00 xps-9320 boltd[1240]:
> [c2010000-0072-Thunderbolt 3 Dock Core ] udev: device changed: authorized
> -> authorized
> 2025-03-03T10:47:42.252854-08:00 xps-9320 boltd[1240]:
> [c2010000-0072-Thunderbolt 3 Dock Core ] disconnected
> (/sys/devices/pci0000:00/0000:00:0d.2/domain0/0-0/0-1)
> ----
>
> But after that, it wouldn't get authorized again until I'd rebooted:
> ----
> 2025-03-03T10:47:42.252854-08:00 xps-9320 boltd[1240]:
> [c2010000-0072-Thunderbolt 3 Dock Core ] disconnected
> (/sys/devices/pci0000:00/0000:00:0d.2/domain0/0-0/0-1)
> 2025-03-03T10:49:24.319123-08:00 xps-9320 boltd[1240]:
> [c2010000-0072-Thunderbolt 3 Dock Core ] parent is 63ae8780-500c...
> 2025-03-03T10:49:24.320239-08:00 xps-9320 boltd[1240]:
> [c2010000-0072-Thunderbolt 3 Dock Core ] connected: connected
> (/sys/devices/pci0000:00/0000:00:0d.2/domain0/0-0/0-1)
> 2025-03-03T10:49:24.320320-08:00 xps-9320 boltd[1240]:
> [c2010000-0072-Thunderbolt 3 Dock Core ] auto-auth: authmode: enabled,
> policy: iommu, iommu: yes -> ok
> 2025-03-03T10:49:24.320368-08:00 xps-9320 boltd[1240]:
> [c2010000-0072-Thunderbolt 3 Dock Core ] auto-auth: security: iommu+user
> mode, key: no -> ok
> 2025-03-03T10:49:24.320449-08:00 xps-9320 boltd[1240]:
> [c2010000-0072-Thunderbolt 3 Dock Core ] authorize: authorization
> prepared for 'user' level
> 2025-03-03T10:49:24.320539-08:00 xps-9320 boltd[1240]:
> [c2010000-0072-Thunderbolt 3 Dock Core ] udev: device changed:
> authorizing -> authorizing
> 2025-03-03T10:49:24.321698-08:00 xps-9320 boltd[1240]:
> [c2010000-0072-Thunderbolt 3 Dock Core ] udev: device changed:
> authorizing -> authorizing
> 2025-03-03T10:49:24.335697-08:00 xps-9320 boltd[1240]:
> [c2010000-0072-Thunderbolt 3 Dock Core ] authorize: finished: FAIL
> (status: auth-error, flags: 0)
> 2025-03-03T10:49:24.335817-08:00 xps-9320 boltd[1240]:
> [c2010000-0072-Thunderbolt 3 Dock Core ] auto-auth: authorization failed:
> kernel error: write error: Cannot allocate memory
This could happen if you unplug the device (or the link goes down) in the
middle of creating PCIe tunnel, it ends up returning -ENOMEM. If you have
dmesg with "thunderbolt.dyndbg=+p" that would help to confirm.
In any other cases (e.g you did not unplug in the middle) this is unexpected.
> 2025-03-03T10:49:59.011121-08:00 xps-9320 boltd[1240]:
> [c2010000-0072-Thunderbolt 3 Dock Core ] disconnected
> (/sys/devices/pci0000:00/0000:00:0d.2/domain0/0-0/0-1)
> ----
>
> Oh, and while I couldn't see any of the USB functions of the dock, the DP
> tunnel was working, the external (cable-attached) monitor was on. There were
> no kernel messages from the failure either (but I didn't have TB dyndbg
> turned on).
>
> Several attempts at reconnecting and a fully-disconnected power-cycle of the
> dock gave the same error until I'd rebooted the laptop. What's interesting
> is my CalDigit dock had no problem being recognized when I'd plugged it in
> during these failures:
>
> ----
> 2025-03-03T11:03:33.383513-08:00 xps-9320 boltd[1240]: [80a78780-00b3-TS4
> ] parent is 833f8780-3179...
> 2025-03-03T11:03:33.385441-08:00 xps-9320 boltd[1240]: [80a78780-00b3-TS4
> ] connected: connected
> (/sys/devices/pci0000:00/0000:00:0d.3/domain1/1-0/1-1)
> 2025-03-03T11:03:33.385585-08:00 xps-9320 boltd[1240]: [80a78780-00b3-TS4
> ] auto-auth: authmode: enabled, policy: iommu, iommu: yes -> ok
> 2025-03-03T11:03:33.385635-08:00 xps-9320 boltd[1240]: [80a78780-00b3-TS4
> ] auto-auth: security: iommu+user mode, key: no -> ok
> 2025-03-03T11:03:33.385733-08:00 xps-9320 boltd[1240]: [80a78780-00b3-TS4
> ] authorize: authorization prepared for 'user' level
> 2025-03-03T11:03:33.387211-08:00 xps-9320 boltd[1240]: [80a78780-00b3-TS4
> ] udev: device changed: authorizing -> authorizing
> 2025-03-03T11:03:33.389891-08:00 xps-9320 boltd[1240]: [80a78780-00b3-TS4
> ] udev: device changed: authorizing -> authorizing
> 2025-03-03T11:03:34.395468-08:00 xps-9320 boltd[1240]: [80a78780-00b3-TS4
> ] authorize: finished: ok (status: authorized, flags: 0)
> 2025-03-03T11:03:34.395641-08:00 xps-9320 boltd[1240]: [80a78780-00b3-TS4
> ] auto-auth: authorization successful
> 2025-03-03T11:03:34.395943-08:00 xps-9320 boltd[1240]: [80a78780-00b3-TS4
> ] udev: device changed: authorized -> authorized
> ----
>
> I'll keep an eye out for it if it happens again, but at least it's not
> crashing!
If possible add "thunderbolt.dyndbg=+p" now to your kernel command line so
if this happens again, we hopefully have full dmesg to investigate.
Otherwise it is hard to diagnose.
next prev parent reply other threads:[~2025-03-04 8:27 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-02 4:57 So, I had to revert d6d458d42e1 ("Handle DisplayPort tunnel activation asynchronously") too, to stop my resume crashes Kenneth Crudup
2025-03-02 5:36 ` Kenneth Crudup
2025-03-02 16:26 ` Kenneth Crudup
2025-03-02 16:30 ` Kenneth Crudup
2025-03-03 10:46 ` Mika Westerberg
2025-03-03 11:02 ` Kenneth Crudup
2025-03-03 11:21 ` Mika Westerberg
2025-03-03 11:38 ` Kenneth Crudup
2025-03-03 11:45 ` Kenneth Crudup
2025-03-03 11:55 ` Mika Westerberg
2025-03-03 12:39 ` Kenneth Crudup
2025-03-03 12:51 ` Kenneth Crudup
2025-03-03 11:53 ` Mika Westerberg
2025-03-03 12:33 ` Kenneth Crudup
2025-03-03 13:13 ` Mika Westerberg
2025-03-03 13:19 ` Kenneth Crudup
2025-03-03 13:23 ` Mika Westerberg
2025-03-03 13:46 ` Mika Westerberg
2025-03-03 13:53 ` Kenneth Crudup
2025-03-03 14:01 ` Mika Westerberg
2025-03-03 14:10 ` Kenneth Crudup
2025-03-03 14:20 ` Mika Westerberg
2025-03-03 14:33 ` Kenneth Crudup
2025-03-03 17:58 ` Mika Westerberg
2025-03-03 18:20 ` Kenneth Crudup
2025-03-03 19:44 ` Kenneth Crudup
2025-03-04 8:27 ` Mika Westerberg [this message]
2025-03-04 12:52 ` Kenneth Crudup
2025-03-04 13:40 ` Mika Westerberg
2025-03-04 13:48 ` Kenneth Crudup
2025-03-04 13:51 ` Mika Westerberg
2025-03-04 17:29 ` Kenneth Crudup
2025-03-05 8:31 ` Mika Westerberg
2025-03-03 14:17 ` Kenneth Crudup
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=20250304082731.GF3713119@black.fi.intel.com \
--to=mika.westerberg@linux.intel.com \
--cc=kenny@panix.com \
--cc=linux-usb@vger.kernel.org \
/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