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/ _______________________________________________ Linux-usb-users@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-users