David Brownell wrote:
>
> Interesting findings, although they're incomplete and not quite
> relevant to the thread's question ... :)
Well, in short: remove all but one UHCI driver so that the remaining
driver (and not 4 of them) can be fixed.
> > 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 logical transfer size (as by scanner protocol) can be several megs
but scanner.c schedules URBs with a maximum transfer size of 32k
(IBUF_SIZE, defined in scanner.h). But even with a maximum URB transfer
size of 128 bytes (that is two times the bulk endpoint's maximum
transfer size) it does not work. Only with 64 bytes it works, always. If
scheduling two URBs with a transfer size of 64 bytes each works, but
scheduling one URB with a transfer size of 128 does not work, what does
that mean to you?
> > 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?
This is a secondary problem because it happens only because of the
failed transfer. But clearly, the scanner was, on the protocol level,
asked to send data, and now there is no one to fetch it. Only a forceful
disconnect on the USB level resets it to a usable state, and that is
what unloading the hcd accomplishes.
> > 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.
I completely agree. The rewrite of read_scanner() was and still is the
only way I can make use of my scanner at all. If the hcd would be fixed
then the scanner module should work fine as it is.
Anyway, I am not the only one having this problem with (usb-)uhci(-hcd).
Just last month (May, that is), there was a thread "Unstable
scanner/usb-uhci/2.4.18 during bulk transfers" on linux-usb-users that
matches my findings. And there are lots of unresolved problems indicated
by "usb_control/bulk_msg: timeout", still in kernel 2.4.18.
Regards
Stephan
_______________________________________________________________
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
