On 23/11/2019 23:56, Chris Murphy wrote: > > What about checking for differences in kernel messages between the > stripped down and stocked kernel, during device discovery. That is > connect no drives, boot the stripped kernel with the problem, connect > one of the problem USB devices, record the kernel messages that > result. Repeat that with the stock Debian kernel that doesn't exhibit > the bug. I'm not sure if you received it in the first email, but I have a zipfile with the dmesg output of both the Debian config and my own config, as well as the configs themselves. If for some reason the mailing list didn't process the attachment, you can download it from here: https://gofile.io/?c=6TaB3p Not sure if there a way to enable more verbose output? > > My guess is this is some obscure USB related bug. There are a ton of > bugs with USB enclosure firmware, controllers, and drivers. > Possibly, although it affects 3 different enclosures, so it should not be something enclosure specific, but affect a common layer. > Also, is this USB enclosure directly connected to the computer? Or to > a powered hub? I have inordinate problems with USB enclosures directly > connected to an Intel NUC, but when connected to a Dyconn USB hub with > external power source, the problems all go away. And my understanding > is the hub doesn't just act like a repeater. It pretty much rewrites > the entire stream. So there's something screwy going on either with > the Intel controller I have, or the USB-SATA bridge chip, that causes > confusing that the hub eliminates. All connected directly to the computer, two via USB-3, one via USB-C, same errors. >
