On Wed, 13 Sep 2017, Bruce Korb wrote: > > This raises some questions: > > > > Can you eliminate the switch entirely as the cause? > > Meaning the switch might be suppressing the mouse interrupts > without also suppressing interrupts from the keyboard, SD card > reader and track pad? It would seem to me that that would require > some highly unlikely specialized firmware. :-D Or buggy firmware. Or a bug in the kernel driver. > > What > > happens if you plug the mouse into the USB-3 hub and plug the > > hub directly into the computer (bypass the switch)? > > I'll try that later today. I've been avoiding that because the physical > back of my tower is not easy to get to. :) It would be nice to know the answer. Just to remove one area of uncertainty. I have known switches in the past to cause problems. > > What happens if you plug the keyboard into the USB-3 hub > > (either with or without the switch)? > > The keyboard is plugged into the hub -- with the switch -- at this moment. > It works. > > > It's clear from the usbmon traces that the computer isn't getting any > > responses to the interrupt URBs (those responses are what the mouse > > uses to send back data about button clicks and motions). But if the > > packets were simply lost, it would show up as an error. It would be > > nice to know what's going on at each side of the hub. No way to do > > that without special hardware, though. > > I captured what happens when plugged into a mobo USB2.0 port. > I know it works when plugged into an add-on 3.0 port (ATA add on). > I know it works when plugged into that same 3.0 port through a switch. > Finally, I know it does *not* work when plugged through a hub and > switch when that 3.0 hub is either my Plugable (powered) brand or > the Kingston connection powered hub. > > WRT "No way to do that without special hardware" perhaps I can > do the tracing on OS/X. Remember, that is still working. I could also > re-install openSUSE 42.1, but I won't. That would be too many > hours of work. No, you can't do it using only the computer, no matter what operating system or software you run. The computer can only tell you what data it gets over the wire; it can't tell you what's happening in the stretch of wire between the hub and the mouse. For that you need a USB bus analyzer. The fact that it works under OS/X means that Linux configures either the xHCI host controller or the hub incorrectly. We need to know which and what it is doing wrong. > The Plugable folks turn out to be very helpful. I was going to send them > a link to this thread, but I cannot find a link. This link: > > http://dir.gmane.org/gmane.linux.usb.general works and leads to > > http://news.gmane.org/gmane.linux.usb.general > http://blog.gmane.org/gmane.linux.usb.general > > which are broken. Here's a link: https://marc.info/?t=150498668400001&r=1&w=2 Alan Stern > Anyway, for now: http://plugable.com/support/plugdebug :) > > More later today. -- 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
