On Thu, Jul 11, 2013 at 11:28 AM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Thu, 11 Jul 2013, Johannes Stezenbach wrote: > >> I took a peek at the usbmon log, and there is one thing I don't get. >> >> $ grep "C Zi:1:005:2" em28xx_usbmon.log | less -S >> >> There are several cases where the isoc descriptor actual length is >> short (< 2892, e.g. 0, 552 or 1928), yet the actual_length for the >> whole URB at the end of the line is still 64*2892 -- is that like it should be? > > Yes. When one packet is short, the following packets don't get moved > up in the buffer -- their offsets are fixed in advance. The unused > space at the end of the short packet remains, and it contributes to the > total actual_length value for the entire URB. > >> Also, is it expected that the em28xx doesn't have data to send for >> some microframes (for analog video capture e.g. during horizontal >> or vertical blank interval)? I guess in the analyzer that should >> show as an IN token with no reply instead of DATA[012] replies. > > Not necessarily. It might send random data, or a short (maybe even > 0-length) reply. > > In fact, the usbmon trace does show some short packets (as you > mentioned above) and even some 0-length packets. For example, see > timestamp 3976305153. > >> Can you confirm that in the error case there is no IN token at all? > > That's what the analyzer log showed. Of course, it's possible that the > analyzer itself was faulty, but I don't think so because Devin said the > missing packets matched exactly with the corrupted data in the > following microframes. > >> And another dumb question: Is there another USB video grabber >> with different hardware which also uses isoc and works? >> E.g. the cx231xx? Or do you think it might have the same missing >> microframe issue but copes better with it due to larger >> buffer space on the device? > > The uvcvideo driver works. But as you point out, the circumstances may > be significantly different. > > Alan Stern > Sorry for the delayed response in contributing to this thread. I've been testing and gathering data all morning. So a few new things: It looks like I may have created some confusion by attempting to correlate the usbmon trace against the Beagle data. I've got two environments I'm debugging on: an x86 box with the stock Intel EHCI HCD, and a Davinci TI8147 ARM system which has the musb HCD. Because I was seeing what visually looks like identical behavior on both platforms, I had been actively going back and forth between them during debugging. In this case, the Beagle trace was collected against the Davinci board but the usbmon traces were collected against the x86 system. I finally ran the Beagle against the x86 system, and found that in fact I'm not getting the intermittent 250us gaps between microframes when corruption occurs (which BTW is entirely consistent with the usbmon trace). Hence we've been trying to figure out why there was a missing microframe in the Beagle trace but not in the usbmon trace, when in fact that was a red-herring and there's no lost microframe to begin with. Looking closer at the Beagle trace on the x86 system -- while there aren't 250us gaps prior to the corruption, there *is* a delay between the SOF and the IN packet on the order of 30-50us. This is present in all instances where there is corruption, and in all other cases the IN packet occurs within 1us of the SOF. I suspect we've got the same basic issue on both platforms where there is a delay between SOF and the IN packet, but the x86 system is so much faster than the ti8147 platform that there's still time to grab the microframe within the frame interval (albeit delayed), while on the 8147 platform the HCD skips the microframe entirely (the HCD is expected to skip a microframe if it concludes that it would not be finished before the next SOF). Because of the difference in behavior between x86 and ti1847, I figured it would be a worthwhile exercise to go back to the 8147 platform and apply the ISO_ASAP fix that Alan mentioned yesterday, as well as a fix for an incorrect spin_lock() call which I had tried on the x86 box but hadn't yet applied to my 8147 tree (which out of dumb luck, Ming Lei happened to submit a patch for this morning as well). http://www.mail-archive.com/linux-usb@xxxxxxxxxxxxxxx/msg24178.html The ISO_ASAP change had no visible effect on the URB handling. However the change from spin_lock() to spin_lock_irqsave() had a unexpectedly *huge* effect. Now essentially every frame is corrupted and it would appear that the system can no longer keep up with the stream. It's not clear to me why this would cause any change in behavior. Probably also worth noting that with that change, I was not getting *multiple* microframes being skipped (e.g. 250, 500, 750us gaps), at a much higher frequency than before. Another strange thing: If I change the completion handler on the 8147 to comment out the actual processing of the URB (such that all the completion handler does is resubmit the URB), the problem disappears. The isoc stream as captured by the Beagle shows no video corruption, and no 250us gaps. If I were to speculate, I think this might be either because I've reduced the overall load on the system (not only is the URB handler not actually doing anything, but the userland code which process the video is no longer receiving frames), or alternatively the URB completion handler takes such a long time to execute that it actually prevents the hardware from sending out microframes (due to raw CPU load, the fact it's happening in interrupt context, or because of some shared lock). No clear conclusions based on all of this, other than that I really need to independently debug on the x86 versus the TI8147 platform, as they are not in fact behaving in the same manner (despite both of them showing essentially the same symptoms in terms of the appearance of the video). Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- 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
