On Thu, 25 Feb 2010, FEI YANG wrote: > > Are you sure the device didn't send a short packet? > It is possible that the device is sending a short packet. > > > URBs can't be killed in the middle of a transaction. > Do you mean if usb_kill_urb gets called in the middle of an ongoing transfer, > 1. the URB would not be given back until the transfer is completed? > Or > 2. the transfer is going to be stopped at the next 512 bytes packet boundary. > > If 1 is true, there is no special handling needed, but if 2 is true, > the driver still need to check for partial transfer. 1 is true for every URB, whether it gets killed or not. Killing an URB in the middle of a transfer forces the transfer to complete early. Quite likely the data will not all be transferred. 2 is also true. (Actually 2 is only approximately true -- the transfer will be stopped at some packet boundary, but it might not be the next one.) URBs are never given back while any of their transactions are in progress. ehci-hcd follows the procedure described in section 4.8.2 of the EHCI spec when unlinking bulk URBs. It waits until the Interrupt on Async Advance bit in the USBSTS register indicates that the URB's queue head is no longer being used by the hardware before calling qtd_copy_status(). > Is there any other possibilities? I don't think so. A USB bus analyzer would allow you to see exactly what packets get sent; then you'd know the answer for sure. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
