On Fri, 10 Jun 2016, Sean M. Pappalardo wrote: > Hello. > > I have a longstanding issue with multiple chatty USB devices on USB bus > 02 acting erratic when activated simultaneously. As soon as the second > device is closed, the first continues communication normally. The > problem does NOT occur on Bus 01 (which has many other devices attached > as well.) It also does not occur in Windows 7 or 10 on the same computer > with the same USB devices plugged into in the same ports. (Even using > the same cross-platform DJ software. :) ) > > For example, playing audio through a USB audio device and using a MIDI > controller: as soon as the second device (MIDI controller) is activated, > both act erratically (audio reduces to a crackle and the MIDI controller > flickers. If I leave them like that for a few seconds, one or both will > disconnect and/or reset.) As soon as the second device is closed, the > first continues communication normally. > > I have tested with Debian 8.5 using kernels 3.16.5 and 4.5.4 as well as > with Fedora 23 (kernel 4.2.3) and the problem is exactly the same. > Again, Windows 7 and 10 do not exhibit the problem. > > My laptop (an HP EliteBook 8440p) has two USB controllers/buses: > Bus 01: (this one works fine) > 00:1a.0 USB controller: Intel Corporation 5 Series/3400 Series Chipset > USB2 Enhanced Host Controller (rev 05) > 00:1a.0 0c03: 8086:3b3c (rev 05) > > Bus 02: (this one has the problem) > 00:1d.0 USB controller: Intel Corporation 5 Series/3400 Series Chipset > USB2 Enhanced Host Controller (rev 05) > 00:1d.0 0c03: 8086:3b34 (rev 05) > > All four USB ports on the laptop itself appear to be hard-wired into bus > 02. I can only plug devices into bus 01 when the machine is in a docking > station (which has an additional set of six USB ports.) > > I've attached the output of lsusb -t in various scenarios: > not.txt - the control condition without the test devices attached > docking.txt - devices attached to bus 01 where *they work correctly* > leftSide.txt - devices attached to one of the four ports on bus 02 where > the problem occurs > rideSideSATAcombo.txt - devices attached to another of the four ports on > bus 02 where the problem occurs > > The test devices in these outputs are an externally-powered American > Audio VMS4.1 DJ controller with integrated audio interface and mouse > pad. But the problem occurs with many different types of devices, > integrated and not. (E.g. a Behringer UCA-202 audio interface and > Stanton SCS.3d MIDI controller or Enttec DMXUSB PRO lighting interface.) > > I have also tested having removed the SmartCard reader shown on Bus 02 > in those outputs (it's an ExpressCard device,) with no change in the > problem. I have also tried blacklisting ehci-pci (in the hope that > ohci-pci would take over) but doing so just leaves both USB controllers > unclaimed and completely non-functional. > > In the past (2.6-era kernels,) I noticed that the audio from the UCA-202 > would buzz whenever the smart card was being accessed and return to > normal afterwards. I had also been able to set the UCA-202 to 44.1kHz > then both it and the SCS.3d would operate correctly. This is no longer > the case. (No matter what sample rate I use, the problem occurs.) > > Though an audio device is the common factor in all of my tests, I don't > believe the problem is ALSA-related because non-audio, non-MIDI devices > are also affected. (An audio device just happens to be a convenient way > to put a decent load on the bus.) Of course let me know if I should take > this to alsa-dev instead. :) The problem is probably related to the fact that you're using a full-speed (USB-1.1) device with periodic transfers. But that doesn't explain why things work okay on bus 1. I suppose it might have something to do with the fact that the docking station contains its own hub. Have you tried plugging the audio devices into a USB-2 hub and plugging the hub into bus 2? > At this point, I'm suspecting a bug (maybe an off-by-one?) in the > ehci-pci driver since bus 01 works perfectly yet 02 does not on the same > hardware. (Though the differing PCI IDs imply that the hardware isn't > exactly the same.) I took a quick look at ehci-pci.c in 4.5 but didn't > find either of these IDs mentioned. That sort of simplistic explanation is very unlikely. The driver treats the two buses identically. And as far as I know, the hardware for the two controllers _is_ exactly the same, apart from the PCI IDs. > Let me know if you need any further information or if there's something > else I should try to narrow this down further. It would help if you can provide the contents of /sys/bus/kernel/debug/usb/ehci/0000:00:1d.0/periodic while the test is running. You'll probably have to mount the filesystem first: mount -t debugfs none /sys/kernel/debug In fact, maybe you can run the same test and capture the contents of /sys/bus/kernel/debug/usb/ehci/0000:00:1a.0/periodic with the devices plugged into the docking station. It would be interesting to compare the two results. Oh yes, and you should also capture the contents of /sys/kernel/debug/usb/devices while each test is running. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
