Alan Stern wrote:
> On Tue, 23 Oct 2007, Phil Endecott wrote:
>
>> Dear Experts,
>>
>> What can anyone tell me about the EOVERFLOW error (-75), reported e.g.
>> as follows:
>>
>> Oct 23 14:45:15 egypt kernel: usb 3-2.1: device descriptor read/all,
>> error -75
>>
>> I understand that it means "babble",
>
> Yes.
>
>> i.e. that the device was still
>> transmitting when the end-of-frame was due.
>
> No. That is, this is one meaning of the word "babble", but in this
> context "babble" means the device was still transmitting when the host
> expected it to stop. In other words, the device sent a larger packet
> than the host expected, like a 64-byte packet when the host expected
> only 18 bytes, or a 3-byte packet when the host expected only 2 bytes.
Thanks Alan. Like declaring a bMaxPacketSize0 of 8, and then when
asked for 18 bytes of device descriptor, returning all 18 in one
packet? That looks like it's my problem!
Aside: while I was trying to understand this, I stumbled upon this code
in core/hub.c. This is in 2.6.19; apologies if it has changed since
then. In hub_irq():
bits = 0;
for (i = 0; i < urb->actual_length; ++i)
bits |= ((unsigned long) ((*hub->buffer)[i]))
<< (i*8);
hub->event_bits[0] = bits;
This is processing the data from a hub's status-change endpoint. My
concern is what happens if more than one port's status changes within
the endpoint's polling interval. It's OK if the hub returns a single
report with all of the appropriate per-port bits set, but is it allowed
to return two reports, one showing one port change and a second also
showing a second port change? I believe that in this case the code
above will attribute the second report to non-existent port numbers and
subsequently ignore them. (I'm not worried about the MaxPacketSize /
babble here - though thinking about that was how I came to look at this
code - it seems to be 16 bytes for my hubs.)
My concern is less about the correctness of the code - after all, if
hub status change reporting was broken, someone would have complained
by now - but more about whether I correctly understand how an interrupt
endpoint works. In general, if an additional event occurs in the
device before a previous one has been seen by the host, does the new
status replace the old one? This would be similar to how a hardware
interrupt-status register would work. However, thinking about a
keyboard you certainly don't want new keypresses to replace old ones
that have not been read yet! So, from the point of view of a device
(e.g. a microcontroller) providing a general-purpose interrupt endpoint
feature, should new data be queued behind old data, or should it
replace it?
Many thanks,
Phil.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-users
