All of lore.kernel.org
 help / color / mirror / Atom feed
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.

  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 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.