On Fri, 13 Feb 2004, Guennadi Liakhovetski wrote: > > If you feel up to it, you could try editing the gphoto2 source. Find the > > part that handles the file listing transfers, and round the transfer > > length up to the next multiple of the maxpacket size (probably 64 but > > check in /proc/bus/usb/devices). > > Well, I did try. It worked. gphoto2 fails every other "list files" > command, because it gets confused by those extra bytes, but, at least, I > don't get the babble...
I'm glad you were able to make some progress at least. > Well, it's not a nice solution, of course. You > can't "fix" every user-space application like that. Of course not. > The driver should be > able to handle such problems. Or, at least, not hang... If you don't want > to mask VIA's bugs, maybe we could just implement a timeout to return with > an error, and, at least, let the user to reload the driver? At the moment, > I can generate one event on the bus (e.g. by re-plugging the camera) to > finish the hanging gphoto2, and one more to unload the driver:-)) I don't know any way to write a true fix. This is one of those difficult situations where you have two pieces of hardware (the camera and the controller), each with their own bug. In isolation those bugs are fairly innocuous but together they are deadly. Sure, if no devices ever violated the USB spec by sending babble packets then the VIA problem wouldn't matter. And if the VIA controller didn't die every time it received a babble packet then it wouldn't matter so much when the camera sent one. At the moment the only possibility I can think of is to add a watchdog timer to the UHCI driver. When it detects that too much time has passed with no interrupts received, it would reset the controller. This would prevent things from hanging indefinitely, but it would also have the unfortunate side effect of re-initializing every USB device connected to the controller. (If the only device connected was your camera, you wouldn't care.) I will probably have to put such a watchdog into the driver, but there are other changes it needs before that can be done. In the meantime, as more people start using the 2.6 kernel, more and more reports accumulate about these failures. Oh well... Alan Stern ------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
