On Tue, 8 Dec 2015, Josh Triplett wrote: > 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. You had a couple of other sysfs directories. Along with /sys/.../2-3.1.2:1.1/power there was also /sys/.../2-2:1.1/0003:17EF:6009.002D/power. The first corresponds to the USB interface (bound to the usbhid driver in this case). The autosuspend values in that directory are nearly meaningless; even when it says the interface is in runtime suspend, it need not actually be. I don't know what the second refers to. Some other device entirely? In any case, what actually matters is what the hardware sees, not what the drivers do, and we know what messages were sent to/from the mouse hardware. The usbmon output shows all of them. And in particular we can rule out suspend as the cause of the problem. _Nothing_ got suspended during the time interval in question (it would have shown up in the usbmon trace). > What do that other sysfs directory's properties mean, if not the actual > suspend state of the device? Basically, they indicate what the PM core thinks is going on. But the PM core doesn't understand the internal workings of every bus subsystem and every driver. For example, in the case of USB consider the difference between your 2-3.1.2 and 2-3.1.2:1.1 "devices". I put the word in quotes because only the first refers to a physical device (the mouse); the other refers to one of the logical interfaces within that device. Suspending a USB device requires that all its interfaces be in their logical suspend state, but suspending an interface while the device remains powered does nothing at all. Neither the hardware nor the driver is aware of the interface's state; the interface driver's runtime PM callbacks are invoked when the device (not the interface!) goes into or out of runtime suspend. > > > > 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. Of course not, since the computer did not receive any messages from the mouse. The usbmon trace shows that no messages were sent at all. > > 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. Yes, but do you observe the same behavior if you use a USB-2 hub made by a different manufacturer from the dock? > Would a USB 2 A-to-A extension cable, without the USB 3 pins, suffice > for such testing? I have one of those. No. > > 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. In any case, it's relatively unlikely that anything appeared on the wire without showing up in the usbmon trace. Possible, but unlikely. 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
