On Thu, 24 Feb 2011, Laurent Pinchart wrote: > Hi everybody, > > I've been trying to solve a weird bulk transfers issue for a couple of weeks > in the uvcvideo driver. It now seems the problem lies in the lower layers (or > even possibly in the device), so I'd appreciate some help to shed light on > this. > > Background information: kernel 2.6.37, EHCI controller, two identical (as far > as the USB interface is concerned) UVC devices plugged into the root hub. The > host sends MJPEG compressed video data to the devices (UVC allows for video > output as well as capture) through bulk endpoints. > > After a random time, one of the device seems to hang. It stops receiving data > on the bulk endpoint. On the host side, the uvcvideo driver submits its bulk > URBs correctly until the hang occurs, at which point the completion callback > stops being called. No error is being reported in the last calls to the > completion callback, and usb_submit_urb() always returns success. The other > device continues to receive data correctly. No message is printed to the > kernel log at that point. Turning USB verbose debugging on doesn't show any > additional message in the kernel log when the freeze occurs. > > A USB analyzer showed that bulk transfers stop completely for the device that > hangs. Three screenshots of the trace can be found at > > http://www.ideasonboard.com/usb/usb-trace-1.jpg > http://www.ideasonboard.com/usb/usb-trace-2.jpg > http://www.ideasonboard.com/usb/usb-trace-3.jpg > > They have all been taken in separate runs of the application. These screenshots aren't definitive. The first shows a bulk transfer to device 6 ending with an NYET handshake, but it doesn't show what happens afterward. The host controller is supposed to send PING packets to the device, which replies with ACK when it is ready to receive more data. The screenshot doesn't show if this happened. The second screenshot is similar. Are the PING packets getting filtered out? The third screenshot shows a bunch of 0-byte transfers. Most likely that's what the application is sending. A usbmon trace would say for sure. > It seems that the device which hangs is the one that is first plugged into the > system (lowest USB address), but this could be a coincidence. The bulk > payloads have variable sizes, and it seems the first 1-byte bulk packet > triggers the freeze (this can again be a coincidence). The freeze occured at > least once without a 1-byte bulk packet though. It also seems that the freeze > can't be reproduced when only one of the devices is in use. > > When the transfer freezes, disconnecting/reconnecting the device is required > to recover from the problem. Stopping the video stream, unloading/reloading > the uvcvideo driver and restarting the video stream isn't enough (no bulk > packet can be transferred at all in that case). Physically > disconnecting/reconnecting the device works, as well as triggering a > disconnection/reconnection through the control endpoint (the device implements > a couple of custom debugging commands, including one which switches its > operation mode and triggers a USB disconnection). This means that endpoint 0 > still responds correctly. > > All help will be appreciated. I've got a couple of (very long) usbmon traces > available if needed. I can also provide specific usbmon traces or kernel logs, > and of course try patches. Try examining your analyzer data in more detail, looking for PING packets and the responses. If the device never replies with ACK then it is hung. If you see any more of those 0-byte transactions, compare them against the usbmon trace. 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
