On 05/13/2009 01:13 PM, Alan Stern wrote: >> 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. > Yes, timestamps would be a great help. >> 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. > I have different firmware with a more complex device descriptor (more interfaces and endpoints), that goes through 6 resets. Have you seen Windows OS perform that many resets during enumeration? Anyway, its good to have an answer. The reason this is an issue to start with is that the firmware and the host app aren't designed to account for resets in the middle of "in" transfers. The device just doesn't have the SRAM or the code size to buffer much. Normally not a problem since resets seem rare, but with vmware/guest running the resets often come after Linux has finished enumeration and started interrupt-in requests. At least I know what to lookout for, if I get tech support calls on this someday. Thank you again for all the feedback Alan. Very much appreciated! -Brad -- 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
