Interesting findings, although they're incomplete and not quite relevant to the thread's question ... :)
> 4. After reading the logs of the usb-uhci driver I noticed that a > requested transfer block gets split in many small data packets of 64 > bytes, i.e the maximum packet size of a bulk transfer which coincides > with my scanner's maximum packet size). These are all scheduled, and > after receiving about half of the requested packets Out of curiousity, how big are the transfers you request? It shouldn't matter, you should be able to provide (somehow) a 1 MByte buffer and see it work just fine, but I don't recall ever hearing about a bug related to the size of the transfer buffer. > the uhci driver logs > that there are no more outstanding packets. This results in a short read > count in scanner.o, and the scanner again responds only after a complete > unload of the uhci driver. That would appear to be a bug somewhere in usb-uhci ... what about the updated/smaller "-hcd" versions? > 5. The behaviour described above does not occur if the transfer size of > calls to usb_bulk_msg is forcibly limited to 64 bytes without changing > any scanner specific parameters. > > </quote> > > As the method described in 5. lead to inacceptable transfer rates I > rewrote read_scanner() in scanner.c so that it schedules lots of URBs > with a payload of 64 bytes each, with every completed URB immediately > rescheduled to keep the transfer rate at maximum peak. Better IMO to fix the real bug than to teach any (every!) driver not to use the "transfers can be much bigger than maxpacket" API feature. - Dave _______________________________________________________________ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
