Somewhere underneath all that sarcasm, I believe that you're saying
that the device is violating the size of the isochronous packets. From
my point of view this means that the packets are too small as I am
interested in getting the device to work, not in fixing its, possibly
broken, USB interface.
However without a complete understanding of the USB stack, I cannot
determine if
a) The host informs the device of the sizes and offsets of the packets
to use, according to the submitted URB, and then the device is supposed
to follow them and if it doesn't you get the -EOVERFLOW? Or
b) The URB merely informs the host what size packets to expect and the
device sends what it has been configured to send and if they dont match
then the -EOVERFLOW occurs?
Jared
Alan Stern wrote:
Please send your messages to the mailing list as well as to me.
On Wed, 2 Aug 2006, Jared Holzman wrote:
Another quick question, what does the status -EOVERFLOW mean for
individual isochronous packets?
All the normal USB error codes are explained in
Documentation/usb/error-codes.txt. -EOVERFLOW status means the received
data packet was larger than expected.
Alan Stern
Could you be a bit more specific. Does that mean:
1) The individual isochronous packets were too small?
No, it means they were too big. That's what "larger than expected" means.
Something that is too small is not "larger than expected".
2) There weren't enough isochronous packets
No, it doesn't mean there weren't enough of them. It means some of them
(the ones that got the -EOVERFLOW status) were larger than expected. In
other words, the actual packet size was larger than the value in
urb-iso_frame_desc[n].length, where n is the index corresponding to the
packet that got the -EOVERFLOW status.
3) The transfer buffer was too small
No, if the transfer buffer were too small then usb_submit_urb() would have
returned an error immediately.
However you could argue that the value in urb-iso_frame_desc[n].length
was too small. That's a matter of your point of view: Either the value of
the length field was too small or the packet size was too big (or possibly
both). All you have told us is that the requirement
(the length field) = (the packet size)
was violated. Without more information I can't say whether the fault
lies on the left side or the right side of the inequality.
4) Something else...
I think by now we have belabored the point sufficiently.
Alan Stern
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
