On Tue, 12 May 2009, Brad Schick wrote: > My theory about a good and a bad device was a red-herring. It must have > been a coincidence, because I now see the problem on both devices. My > next thought was that this could be related to Vmware running on this > box (currently the only convenient way to program the devices). Perhaps > the Vmware daemon is conflicting with the kernel during device enumeration? That's kind of an important piece of information. It sounds like VMware is the user program I was talking about in my earlier email. VMware doesn't conflict with the kernel during device enumeration. Rather, the guest operating system does its _own_ enumeration. Presumably that is the source of the resets you see. > I shutdown Vmware and the problem has stopped, although restarting > vmware and running an vm did not cause the resets to return. So I'm not > totally sure, but it is my prime suspect. I'll keep experimenting. > > I also forgot to mention that (as expected) my system log is full of: > > kernel: [71562.713036] usb 1-1.1.2: reset full speed USB device > using ehci_hcd and address 115 > > I noticed someone else mentioned resets like this in a thread about mass > storage a while back, but there was no resolution beyond "the cause is > unknown". Taken out of context, this comment is a little misleading. The cause of the resets is very well known; they occur because the mass-storage device stops responding to commands. What we don't know is why the device stops responding. 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
