вторник

[Bug 1962349] Re: Bolt doesn't work with native USB4 hosts

** Changed in: linux-oem-5.17 (Ubuntu)
Status: Fix Committed => Invalid

--
You received this bug notification because you are subscribed to linux
in Ubuntu.
Matching subscriptions: Bgg, Bmail, Nb
https://bugs.launchpad.net/bugs/1962349

Title:
Bolt doesn't work with native USB4 hosts

Status in OEM Priority Project:
New
Status in bolt package in Ubuntu:
Fix Released
Status in linux package in Ubuntu:
In Progress
Status in linux-oem-5.14 package in Ubuntu:
Invalid
Status in linux-oem-5.17 package in Ubuntu:
Invalid
Status in bolt source package in Focal:
Fix Released
Status in linux source package in Focal:
Won't Fix
Status in linux-oem-5.14 source package in Focal:
Fix Released
Status in linux-oem-5.17 source package in Focal:
Invalid
Status in bolt source package in Impish:
Fix Released
Status in linux source package in Impish:
Won't Fix
Status in linux-oem-5.14 source package in Impish:
Invalid
Status in linux-oem-5.17 source package in Impish:
Invalid
Status in bolt source package in Jammy:
Fix Released
Status in linux source package in Jammy:
In Progress
Status in linux-oem-5.14 source package in Jammy:
Invalid
Status in linux-oem-5.17 source package in Jammy:
Fix Released

Bug description:
[SRU Justification]

[Impact]

 * AMD Yellow Carp provides integrated USB4 host controllers
 * When plugging in a Thunderbolt3 or USB4 device, users are unable to authorize it using the GUI due to an error message: "parent not authorized, deferring"

[Test Plan]

AMD Yellow Carp Host (issue this bug is about)
----------------------------------------------
 * Plug in USB4 device or TBT3 to AMD Yellow Carp host
 * Ensure that PCI topology has populated
 * Observe that /sys/bus/thunderbolt/devices/DEVICE/authorized is "0"
 * Try to run `boltctl enroll $UUID`

Alpine Ridge / Titan Ridge host (discrete controller)
------------------------------------------------------
Start out on a host with discrete controller (Alpine Ridge or Titan Ridge)
1. sudo boltctl forget -a
2. Plug in dock
3. Make sure 'boltctl list' enumerates dock.
4. Check /sys/bus/thunderbolt/devices/domain0/iommu_dma_protection (value dependent upon host)
   - If 0; try to manually enroll using 'boltctl enroll $UUID'
   - If 1; ensure that device automatically enrolled with bolt.

GUI Check
---------
Ensure that devices show up in the Settings GUI and are now able to authorize.
Note: for AMD platforms enumerating PCIe devices is a separate problem from BOLT handled by kernel tasks. GUI check is only about "authorization".

[Where problems could occur]

 * Intel USB4 or TBT3 hosts also use bolt. They could have a problem with the new version of bolt.
 * This is very unlikely however since there is a through test suite, and up until now the entire industry has been using bolt on Intel controllers for a long time.
 * There haven't been any significant bugs reported upstream or in Ubuntu since 0.9.1 release.

[Other Info]
 * This bug also occurs on Intel controllers from ICL, TGL or ALD, but in many cases they are automatically authorized to an iommu DMA policy.
 * It is fixed in bolt 0.9.1 or later release.
 * To solve the SRU, will backport 0.9.1 release from Impish.
 * I did look into backporting just the commit(s) for fixing this, but it's not a trivial backport. Quoting the changelog (https://gitlab.freedesktop.org/bolt/bolt/-/blob/master/CHANGELOG.md): "Additionally the unique_id of said host controller changes with every boot, which breaks one of the fundamental assumptions in boltd".

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1962349/+subscriptions

Комментариев нет:

Отправить комментарий