> Could you propose some tests that could be ran to check for regressions?
Sure. I'll modify the description to include some specific tests and change the status back to "In Progress" when I do. > but is it possible that someone could rely on the boltd binary externally The daemon isn't directly interacted with beyond being launched, but registers a namespace with dbus. IOW a dbus client doesn't care where the binary is as the dbus name didn't change. A user would need to have gone out of their way to disable the systemd unit and manually run the daemon themselves from a different launcher script. That's a pretty big change that I think this is very unlikely and not really a big concern here in my mind. ** Description changed: [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. + * 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". + * 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". ** Changed in: bolt (Ubuntu Focal) Status: Incomplete => In Progress -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-oem-5.14 in Ubuntu. 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: In Progress Status in bolt source package in Focal: In Progress Status in linux source package in Focal: Won't Fix Status in linux-oem-5.14 source package in Focal: In Progress 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: In Progress Bug description: [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 -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
