On Wed, 13 May 2009, Brad Schick wrote: > On 05/13/2009 07:19 AM, Alan Stern wrote: > > On Tue, 12 May 2009, Brad Schick wrote: > > > > > >> Thanks for the feedback. VMware perhaps should have been an obvious > >> candidate, but I built the device and it's firmware myself so I was > >> focusing on where problems usually reside... in my own work. > >> > > > > Pardon me for sounding rude, but in this case that seems ridiculous. > > The device isn't capable of initiating a port reset; only the host is. > > So if you're looking for the source of those resets, why concentrate on > > the device? > > > > Doesn't seem ridiculous at all. The host can reset a device if it > detects a problem a transfer (as mentioned in the mass storage case). Right, which means that you need to determine if the host has detected a problem. That is different from detecting a problem on the device side; you need to find out what the host is doing. > It > would also seem logical that a host controller might do a reset if > something was wrong electrically. No, a host controller will not do a reset unless it is told to do so by the driver. > And that was the point of my original question... how can I figure out > what is causing resets. Your replies have been helpful, and yes a bit > rude sounding. I really appreciate the info, so as requested, I pardon you. Sorry for sounding rude; with email sometimes things come across in ways that weren't intended. Have you been able to reproduce those resets? Have you tried setting the usbfs_snoop=y parameter for usbcore? 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
