On Sun, Mar 09, 2025 at 09:57:21PM +0000, Colin Evans wrote: > > In theory, turning off power to port 4 might stop all the events from > > being reported. You can try this to see if it works: > > > > echo 1 >/sys/bus/usb/devices/2-0:1.0/usb2-port4/disable > > > > Alan Stern > > Thank you, that is very helpful, for a couple of reasons. > > "Machine 2" is a new build, so if (as it sounds) the motherboard has a > hardware problem, then I need to > look into returning it. > > BTW- it seems I spoke too soon about the USB stick suppressing the error. > After a couple of reboots with > it in place the problem re-occurred. It does seem that connecting a hub > (switch) is the only way > to reliably stop the error. The switch has a bunch of wiring connected to > USB peripherals and other > machines. I would have guessed that might make the likelihood of picking up > electrical noise > actually worse, but that seems not to be the case here. It may have something to do with whether the attached device is USB-3 or USB-2. Hubs are both (or are USB-2 only). > "Machine 1" is several years old, it's actually the guts of the same PC that > was upgraded to make M/c 2. > It's not usable, or sellable, with this performance hit happening. I have > tried all the external USB ports > on this machine and not found the failing controller, my guess is it's going > to be one that supports > some of the on-board USB headers. In fact, the port in question might not be attached to anything, or improperly grounded, or something like that. > I had been looking on the web for a way to shut down the problem port, or > worst case the whole hub, > however all the Linux examples I found worked by either- > > a) Preventing the loading of the driver for the chipset, by type. However > that would kill all ports supported by > the same type of controller, and this motherboard has multiple > controllers of the same type onboard. > > b) Shutting down a port by searching for the connected device identifier. > However in these cases there > _are_ no connected devlces, the fault happens when the controller is not > connected to anything. > > Hopefully the command you recommended will do the trick, I will let you > know. > > Would I be correct in thinking this would need to be run at every boot, some > time after device enumeration, > or would it need to be run after every re-enumeration of devices after a USB > device is connected / > disconnected? Not sure how to achieve that. At every boot. It doesn't have to be after all the other devices are enumerated; after the USB controller itself is enumerated will be good enough. > I very much appreciate your help in identifying the fault. Thank you. You're welcome. Alan Stern
