Pieter Nagel wrote:
>
> Here is the syslog of what happens (produced with scanner.c compiled
> with DEBUG on):
>
> Oct 1 01:31:35 basilisk kernel: scanner.c: read stats(0): result:0 this_read:32768
>partial:22960 count:45920
> Oct 1 01:31:35 basilisk kernel: usb-uhci.c: interrupt, status 3, frame# 1749
> Oct 1 01:31:35 basilisk kernel: scanner.c: read stats(0): result:-75
>this_read:13152 partial:13120 count:13152
> Oct 1 01:31:35 basilisk kernel: scanner.c: read_scanner(0): funky result:-75.
>Consult Documentation/usb/scanner.txt.
> Oct 1 01:31:45 basilisk kernel: usb_control/bulk_msg: timeout
> Oct 1 01:31:45 basilisk kernel: scanner.c: read stats(0): result:-110 this_read:8
>partial:0 count:8
>
> The application is trying to scan at 2870 pixels wide @ 64bitRGBI. That
> is 22960 bytes of data per scanline.
So one scanline is 22960 = 358 * 64 + 48 bytes (assuming wMaxPacketSize
= 64).
> In the log, you can see the app asking for 45290 bytes of data (2
> scanlines). scanner.c asks for the first 32768 bytes of that.
Here is the application error (faulty implementation of your scanner
hardware's protocol): The application is asking the scanner module for
two scanlines at once instead of just one scanline at a time. Your
hardware seems to consider one scanline as a logical transfer which is
terminated by a short packet (48 bytes in the example). Asking for more
than one scanline (= one logical transfer) in one call to read_scanner
_must_ fail (as you found out). So simply fix your application and
everything should work fine.
> The scanner does not return the 45290 in one continuous bulk transfer.
> It does a bulk transfer of one scanline, 22960 bytes, which is not a
> multiple of wMaxPacketSize.
>
> Next time round, scanner.c does a usb_bulk_msg read for 13152 =
> 45920-32768 bytes, as if it actually got 32768 bytes from the scanner.
Not "got", but "tried to get".
> 13152 is not a multiple of wMaxPacketSize either. It is also less than
> the next scanline of 22960 that the scanner wants to send. Voila!
> babble/EOVERFLOW when the scanner tries to bulk transfer the packet with
> bytes 13120-13184, but linux expects the transfer to end with a 32-byte
> sized end-of-bulk transfer packet.
>
> Thereafter one sees usb_control/bulk_msg timeout in the log forever,
> even after the userpsace app that is still blocking on the failed read
> is killed, as far as I remember; as if the module is stuck inside the
> syscall. The scanner module is unusable, even after rmmod/insmod. One
> must reboot.
>
> If scanner.c asks 22960 (45290-22960, ie count-partial, instead of
> count-this_read), there is no problem.
>
> On Wed, 2002-10-09 at 00:53, Stephan Feder wrote:
> > I do not see how a kernel oops could be caused by the code in scanner.c.
> > Could you give a pointer to the offending piece of code?
>
> In my experience, OOPSen only happen on desperate attempts to
> rmmod/insmod scanner module once it is already hosed.
>
> The real problem is the broken read behaviour. I am not that concerned
> about oopses when rmmoding a module stuck in a syscall.
>
> > >From scanner.c:
> >
> > count -= this_read; /* Compensate for short reads */
> >
> > I would say that the behaviour you describe is quite on purpose.
>
> I fail to understand how pretending that you received 32768 bytes of
> data when you actually receive only 22960 can be "on purpose".
Look at the code. It just says: "I have tried to read 32768 bytes and
got only 22960 bytes, but I won't try again to read what I could not get
in the first place, and will continue with what was not tried yet."
I do not say that your proposal of a different short packet handling is
nonsense (in your case, at least, it would make much sense). But other
applications might break if you change the behaviour you consider
broken. So IMO, you should ask first.
Regards,
Stephan
PS: What you propose is almost a generic bulk pipe interface. But,
AFAICS, mapping the behaviour of read(2) onto USB bulk
pipes/transfers/packets is hard, if not impossible.
--
> > >From scanner.c:
> >
> > this_read = (count >= IBUF_SIZE) ? IBUF_SIZE : count;
> >
> > As IBUF_SIZE is a multiple of wMaxPacketSize all requested packet sizes
> > will be except for the very last packet.
>
> Not when count drops below IBUF_SIZE, and is no longer a multiple of
> wMaxPacketSize, before the very last packet has actually been sent,
> because count is decremented too much.
>
> --
> ,_
> /_) /| /
> / i e t e r / |/ a g e l
> http://www.nagel.co.za
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> [EMAIL PROTECTED]
> To unsubscribe, use the last form field at:
> https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
