Hi Alan, On Friday 25 February 2011 20:00:23 Alan Stern wrote: > 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. It seems so. I've asked for more traces to be captured, and it turns out that the device (based on a CY7C68001 chip) keeps NAKing PING packets. The problem is thus on the device side (where exactly remains to be found out, but that's not a linux-usb issue :-)). Thanks for your help. -- Regards, Laurent Pinchart -- 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
