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.
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.
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.
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".
> >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
