On Wed, 13 May 2009, Brad Schick wrote: > I'll answer myself... I'd assume this is because usbmon shows all usb > activity and not just that from user space usbfs calls. Right. > It would still > be nice to have a good way to correlate the logs beyond manually > matching up requests and responses. I'm not sure how that could be done. usbmon runs at a layer where there's no particular information about the origin of an URB. Detailed comparison of timestamps, perhaps? But remember, the kernel logs generally aren't intended for automatic analysis; they are meant to be read manually. > Looking at the logs with that in mind, what it looks like to me is: > - kernel starts an enumeration process > - vmware claims the interface and resets it > - vmware starts its own enumeration calls > - vmware resets the interface again > - vmware continue enumeration calls You've got it. > Its also look like the kernel may be doing its own enumeration again > after each reset. To be expected? Yes, although it's more of a verification than an enumeration. The kernel needs to verify that the reset hasn't caused the device to change in any essential way (by running a new firmware image, for example). If it did then the kernel would have to re-enumerate the device from the beginning. > Assuming this analysis is accurate, I guess that answers my question. I > wonder what vmware would say about all this. I imagine they'd agree with your conclusions. You're seeing a guest OS go through its virtualized enumeration. 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
