On Tue, Dec 08, 2015 at 11:04:00AM -0500, Alan Stern wrote: > On Mon, 7 Dec 2015, Josh Triplett wrote: > > > > You're looking at the wrong files. The files to monitor are the ones > > > in /sys/devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3.1/2-3.1.2/power > > > (assuming that this device really is the mouse and not something else). > > > Handy shortcut link: /sys/bus/usb/devices/2-3.1.2/power. > > > > Based on the idVendor and idProduct in that directory, that device is > > the keyboard/mouse combo device, yes. > > > > That power directory has many more files, but nothing obvious: > ... > > ==> /sys/devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3.1/2-3.1.2/power/control <== > > on > > That's the important one. It means the mouse isn't going to be > autosuspended. So it doesn't matter that the other sysfs directory (the one listed by dmesg for the mouse input device, containing the :1.1) showed up with autosuspend enabled and the device suspending after a moment, roughly matching the "works for a second and then stops" behavior? That seems entirely too coincidental. What do that other sysfs directory's properties mean, if not the actual suspend state of the device? > > > For more information on what's happening, try collecting a usbmon trace > > > for bus 2 (see Documentation/usb/usbmon.txt). > > > > Done. I started a trace, plugged in the device, moved the mouse a > > little (which moved the pointer for a moment and then stopped > > producing any result), typed a couple of keys (which did work), moved > > the mouse a bit more (which didn't), and unplugged the device. > > > > Trace attached. > > Well, the trace shows the mouse being plugged in and enumerated. Then > it shows the pointer being moved for about half a second, and a couple > of keys typed. 2.7 seconds later, it shows the device died and the > port was disconnected -- I assume that's when you unplugged the mouse. > > During that 2.7-second interval, the usbmon trace shows nothing at all. > No activity from the mouse (although it appears to have been > communicating okay because the computer polled it at 8-ms intervals and > didn't get any errors). And in particular, no suspends. I moved the mouse again during that interval, but the cursor did not respond. > It looks like there's something funny going on between the dock and the > mouse. For instance, maybe the dock doesn't provide quite enough > power. This is just a keyboard/mouse; it doesn't draw significant power from the port, and doesn't require a powered port. > Or maybe the dock's internal hub doesn't work quite right. > It's also possible that something strange happened in the xHCI host > controller, but that seems less likely. You could test it by > removing the dock and then connecting the mouse to the computer by way > of a USB-2.0 hub. If it makes any difference, the dock has both USB 2 and USB 3 ports; I observe the same behavior in both. Would a USB 2 A-to-A extension cable, without the USB 3 pins, suffice for such testing? I have one of those. > I don't have any other good suggestions for further debugging. You did > check the kernel log to see if anything unusual showed up, right? Yes, and nothing did. dmesg shows the input devices showing up, but no USB-related messages after that. > About the only thing I can think of at this point is to use a USB > analyzer between the dock and the mouse. Not something I have handy. - Josh Triplett -- 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
