Hi,
On Tue, Sep 12, 2017 at 8:48 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote:
> On Tue, 12 Sep 2017, Bruce Korb wrote:
>>
>> So, I unplugged and re-plugged my G400 mouse into that switch.
>> I then made sure the mouse was still responded to (it was)
>> and finally unplugged it again.
>> I did that over a 14 second period from 553.78 thru 566.
>>
>> Next, I plugged the hub back in. It has 7 external ports and one more
>> that is used to cascade the second VIA chip. After loading those up,
>> it found the G500 mouse that I had left plugged in. These entries
>> in dmesg are at 577 through 579 seconds.
>>
>> At 582.6 seconds, I plugged in the G400 mouse into the hub.
>> I futzed with it for a while, but it would not work.
>>
>> At 595.6 seconds, I removed my keyboard from the back of the computer
>> and plugged it into the switch. works fine. At 603.7 seconds, the mouse
>> is now plugged back into the back usb port and all is working (G500 aside).
>>
>> While all of this was going on, I was catting /sys/kernel/debug/usb/usbmon/2u
>> into a file.
>>
>> Now, what? :) Thank you!!
>
> 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
> 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. :)
> 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.
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.
Anyway, for now: http://plugable.com/support/plugdebug :)
More later today.
--
- Bruce
--
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
