On Thu, 9 Mar 2023 20:04:15 +0000 Brian Morrison <bdm@xxxxxxxxxxxxx> wrote: > On Wed, 8 Mar 2023 17:16:01 +0200 > Mathias Nyman <mathias.nyman@xxxxxxxxxxxxxxx> wrote: > > > > > Looks like that those devices initially enumerated fine, but > > suddenly disconnect about 19 seconds after boot. > > > > [ 19.155556] usb 2-1.1: USB disconnect, device number 4 > > [ 19.155685] cp210x ttyUSB0: cp210x converter now disconnected > > from ttyUSB0 [ 19.159290] usb 2-1.4: USB disconnect, device > > number 6 [ 19.242344] usb 2-1.4: 3:0: failed to get current value > > for ch 0 (-22) [ 20.100761] usb 2-4.1: USB disconnect, device > > number 8 [ 20.100894] cp210x ttyUSB1: cp210x converter now > > disconnected from ttyUSB1 [ 20.100999] cp210x 2-4.1:1.0: device > > disconnected [ 20.107188] usb 2-4.2: USB disconnect, device > > number 9 [ 20.107253] cp210x ttyUSB2: cp210x converter now > > disconnected from ttyUSB2 [ 20.107284] cp210x 2-4.2:1.0: device > > disconnected [ 20.111938] usb 2-4.4: USB disconnect, device > > number 10 [ 20.181363] usb 2-4.4: 3:0: failed to get current > > value for ch 0 (-22) > > > > Interestingly those are all the devices behind external hubs. > > > > Bisecting this to find the offending commit would be best, but a > > dmesg with xhci and usb core dynamic debug enabled could also show > > why those devices disconnect. > > > > Adding "usbcore.dyndbg=+p xhci_hcd.dyndbg=+p" to your kernel cmdline > > should do this. > > In addition to the debug output I have been looking at the diff > between kernel-6.1 and kernel-6.2 in the /drivers/usb tree, in > particular under /drivers/usb/core/hub.h and /drivers/usb/core/hub.c > where the vendor for this device with VID 0451 is newly listed > although its PID is not: > > Bus 003 Device 002: ID 0451:2046 Texas Instruments, Inc. TUSB2046 Hub > > this device is missing from lsusb output in kernel 6.2.2 but is > present with kernel 6.1.* I was wrong about this, it's the devices on the far side of the TI and SMSC hub devices that are missing, not the hubs themselves. > > In my inexpert way I think it is all tied in to changes from a few > months ago (November 2022) that went into the 6.2rc kernels where the > early_stop capability was added to USB enumeration but I am certainly > not smart enough to identify exactly why the particular combination of > hardware I have is caught up in it. I can see from the extended dmesg > output that certain USB interfaces are unregistered for no obvious > reason and that once this happens they are invisible to the OS. The > altered USB core code would seem to be a prime suspect as the cause of > this regression. > Further testing with kernels 6.1.18 and 6.2.5 is added to the bug entry here: https://bugzilla.redhat.com/show_bug.cgi?id=2175534#c12 I don't know how to bisect this with the available Fedora kernels. -- Brian Morrison
