I'm sorry, it looks like I won't be able to validate this fix on our Ubuntu Core 20 systems. While waiting for this fix to become available, we've used Ubuntu Core's refresh control (snap gating) mechanism to ensure a non-affected version of the pc-kernel snap is installed across our fleet of devices. Relevant docs: https://ubuntu.com/core/docs/refresh-control
Due to this snap gating "validation assertion" currently being in-place, I'm unable to update my test system to the fixed revision of the pc- kernel snap (5.4.0-109.123.1, revision 978) to confirm the fix. I have a pending support ticket with Canonical to find out how to lift the snap gating restriction but at this time I haven't received a response yet. However, I see that the fix has now been marked as released for Focal. Indeed, the fixed revision of the pc-kernel snap (5.4.0-109.123.1, revision 978) has already hit the "20/stable" channel as of today. Can I conclude that the fix has been accepted based on Chris Chiu's confirmation and that my confirmation is no longer required? In other words: that the fix is now released and no longer at risk of being dropped, for 20.04? -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1968210 Title: USB devices not detected during boot on USB 3.0 hubs Status in linux package in Ubuntu: Incomplete Status in linux source package in Focal: Fix Released Status in linux source package in Impish: Fix Committed Bug description: [SRU Justification] [Impact] There are users with certain intel xHCI controllers that are experiencing problems with USB devices not being detected at boot. This is because when the primary roothub is registered, device enumeration happens before xHC is running and leads to devices not being detected. This results in the error that looks something like 'usb usb1-port3: couldn't allocate usb_device'. [Fix] Register both root hubs along with the secondary hcd for xhci. This original fix was reverted upstream due to regressions that occured due to racing that happened when both roothubs were registered simultaneously. However with those fixes being addressed in commits ("usb: hub: Fix usb enumeration issue due to address0 race") ("usb: hub: Fix locking issues with address0_mutex") the maintainers have stated that they will be reintroducing this commit. So lets reintroduce it here to fix the issues that users are experiencing. [Test Case] Confirmed by Chris Chiu that this issue exists on similiar hardware reported by the users and that reverting these reverts fixes the issue showing no signs of 'couldn't allocate usb_device' and with USB devices available after boot. [Regression Potential] Should be low now that we carry the fixes that seemed to be caused by this patch series. ------------------------------------------------------------------------ There have been reports by some users using certain intel xHCI controllers that their USB devices are not being detected after boot again after similar issues were previously found and fixed. This seems to be related to both [1][2] with the majority of the discussion on [1] about these problems reoccurring. This bug report is being made more for documentation of this new regression. These seems to be due to the patchset for [2] being reverted upstream due to regressions. [1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1939638 [2] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1945211 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1968210/+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
