On 4.11.2021 1.54, Mathias Nyman wrote: > On 3.11.2021 16.59, Alan Stern wrote: >> On Wed, Nov 03, 2021 at 08:14:35PM +0530, Kishon Vijay Abraham I wrote: >>> + Alan, Chris, Mathias, linux-usb >>> >>> Hi Hans, >>> >>> On 03/11/21 6:18 pm, Hans de Goede wrote: >>>> Hi, >>>> >>>> On 11/3/21 10:07, Greg Kroah-Hartman wrote: >>>>> On Wed, Nov 03, 2021 at 10:02:52AM +0100, Hans de Goede wrote: >>>>>> Hi Greg, >>>>>> >>>>>> We (Fedora) have been receiving multiple reports about USB devices stopping >>>>>> working starting with 5.14.14 . >>>>>> >>>>>> An Arch Linux user has found that reverting the first 2 patches from this series: >>>>>> https://lore.kernel.org/all/20210909064200.16216-1-kishon@xxxxxx/ >>>>>> >>>>>> Fixes things (the 3th patch is just some mostly unrelated refactoring/cleanup). >>>>>> >>>>>> See here for the Arch-linux discussion surrounding this: >>>>>> https://bbs.archlinux.org/viewtopic.php?pid=2000956#p2000956 >>>>>> >>>>>> And here are 2 Fedora bug reports of Fedora users being unable to use their >>>>>> machines due their mouse + kbd not working: >>>>>> >>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=2019542 >>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=2019576 >>>>>> >>>>>> Can we get this patch-series reverted from the 5.14.y releases please ? >>>>> >>>>> Sure, >>>> >>>> Thanks. >>>> >>>>> but can you also submit patches to get into 5.15.y and 5.16-rc1 >>>>> that revert these changes as they should still be an issue there, right? >>>> >>>> Yes I assume this is still an issue there too, but I was hoping that >>>> Kishon can take a look and maybe actually fix things, since just >>>> reverting presumably regresses whatever these patches were addressing. >>>> >>>> We've aprox 1-3 weeks before distros like Arch and Linux will switch >>>> to 5.15.y kernels. So we have some time to come up with a fix >>>> there, where as for 5.14.y this is hitting users now. >>> >>> Is the issue with PCIe USB devices or platform USB device? Is it specific to >>> super speed devices or high speed device? >> >> Look at the bug reports. They are on standard PCs (so PCIe controllers) >> and some of them involve full speed (mouse and keyboard) devices. >> Although it looks like the problem has little to do with the device and >> a lot to do with the controller. >> >> Is there a good way to get more information about what is going wrong? >> For example, by enabling tracepoints in the xhci-hcd driver? >> >> Alan Stern >> > > To enable xhci traces and dynamic debug at boot please add: > "usbcore.dyndbg=+p xhci_hcd.dyndbg=+p trace_event=xhci-hcd trace_buf_size=80M" > to the kernel cmdline before booting. > (info added to https://bugzilla.redhat.com/show_bug.cgi?id=2019788 as well) > > Symptoms look similar to an old race issue where two usb devices were reset at the same time. > xHC HW can't handle this, and to prevent it the hcd->address0_mutex was added. > > for details see: > https://lkml.org/lkml/2016/2/8/312 > > -Mathias > Looks like it really is an issue with address0_mutex in hub.c not preventing two xhci slots from entering default state at the same time during retry. Seems extending the mutex across retries resolved this, details: https://bugzilla.redhat.com/show_bug.cgi?id=2019788 I'll post that patch here on linux-usb for review shortly -Mathias
