Le mardi 27 mai 2008 ? 16:24 -0400, m. allan noah a ?crit : > On Tue, May 27, 2008 at 4:01 PM, Nicolas <nicolas.martin at freesurf.fr> > wrote: > > > > Le mardi 27 mai 2008 ? 15:42 -0400, m. allan noah a ?crit : > >> On Tue, May 27, 2008 at 3:29 PM, Nicolas <nicolas.martin at freesurf.fr> > >> wrote: > >> > Le lundi 26 mai 2008 ? 19:12 -0400, m. allan noah a ?crit : > >> >> two random thoughts- > >> >> > >> >> 1. can he try 32 bit kernel on same exact machine, just to rule out > >> >> hardware problems? > >> > > >> > Good point, and to try other USB ports on the same machine, that needs > >> > to be confirmed first as it could be a HW issue > >> > > >> >> 2. is there a pattern to the timeouts, like always same number of > >> >> errors before a good packet? > >> > > >> > It looks to be a repetitive pattern, i.e. error occurs on a second > >> > "read" sequence when reading image data, but occurs also sometimes with > >> > smaller transaction control messages (write message, then read response > >> > immediately). > >> > I've asked to give a try with a small tempo between two successive image > >> > data readings, but do not have feedback yet. > >> > > >> > Thanks > >> > > >> > >> yes- it could be that his machine is too fast for the scanner, not > >> that it is 64 bits. > >> > >> allan > > > > But this would mean that with machines getting faster and faster, > > something needs to be adjusted, so that consecutive usb commands do not > > occur within a too short delay. > > > > Unfortunately, I did not see any spec for such timings in libusb. > > Maybe something about that is the usb spec ? need to check this point... > > > > Nicolas > > > > there is no way to control this in libusb AFAIK, instead, you would > have to determine a dynamic delay period to add before all commands. > > allan
Probably will propose a static delay, even if that does not optimize transfer speed performance (is that important for a scanner anyway ?), it will be IMHO, more robust. Nicolas
