On 5/12/2009 7:14 PM, Alan Stern 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. > 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. The device has a "vendor specific" class and protocol. There are no drivers for the device on any OS. It is only accessed through libusb on Linux, and the resets are occurring even when that libusb program is not running. I can see that the guest's enumeration could be causing resets, but I didn't assume that ruled out VMware itself. I don't know Vmware well, how does it pass through usb devices to the guest operating system? Is there a kernel module involved or would resets from the guest OS > VMware come from user land? After a full day of hunting, I'm now unable to cause the problem to happen. I haven't thought of anything relevant that has changed... other than timing. I'm still working on it. >> 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. > Well actually, my comment is not misleading wrt the thread I read. The answer given was: "...they have a cause as yet unknown". Maybe that is now outdated information. -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
