--- linux-2.6.11-rc3.orig/drivers/usb/core/devio.c 2005-02-05 10:41:56.000000000 +0100
+++ linux-2.6.11-rc3/drivers/usb/core/devio.c 2005-02-07 01:35:11.000000000 +0100
@@ -661,8 +661,9 @@
}
kfree(tbuf);
if (i < 0) {
- dev_warn(&dev->dev, "usbfs: USBDEVFS_BULK failed "
- "ep 0x%x len %u ret %d\n", bulk.ep, bulk.len, i);
+ if (i != -ETIMEDOUT)
+ dev_warn(&dev->dev, "usbfs: USBDEVFS_BULK failed "
+ "ep 0x%x len %u ret %d\n", bulk.ep, bulk.len, i);
return i;
}
return len2;
--- linux-2.6.11-rc3.orig/drivers/usb/core/message.c 2005-02-05 10:41:57.000000000 +0100
+++ linux-2.6.11-rc3/drivers/usb/core/message.c 2005-02-07 01:40:22.000000000 +0100
@@ -65,12 +65,10 @@
status = urb->status;
/* note: HCDs return ETIMEDOUT for other reasons too */
if (status == -ECONNRESET) {
- dev_warn(&urb->dev->dev,
- "%s timed out on ep%d%s\n",
- current->comm,
- usb_pipeendpoint(urb->pipe),
- usb_pipein(urb->pipe) ? "in" : "out");
- status = -ETIMEDOUT;
+ if (urb->actual_length > 0)
+ status = 0;
+ else
+ status = -ETIMEDOUT;
}
if (timeout > 0)
del_timer_sync(&timer);
An explanation:
timeouts are an integral part of the usbfs / libusb concept as it stands, it is not an error to get
a timeout and shouldn't be logged as such. My libusb driver has a 1s timeout to allow interruption
of the driver process in case no data is received. This logging makes the text console unusable
during the time in which the driver is running (all the time :-))
The check for actual_length > 0 is to fix a bug in which valid data is discarded when the transaction
is aborted (timed out). There is no way to pass the error code and the data length back to user space
as it has a standard error code negative / data length positive interface and I don't care that the
transaction is timed out as the timeout is arbitrary anyway. I believe all libusb applications will
much prefer to receive their data than know that their transaction has timed out and that they
have possibly (likely) lost an unknown amount of data.
I posted a comment a few days ago to the same effect which was ignored but I feel the discarding
of valid data should at least be justified by those who maintain this code though I can't imagine what
that justification might be.
Another comment: it seems like the data loss is worse for ohci than for ehci but both lose data in this way.
/Brian
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
