Hi, --- On Wed, 7/7/10, Laurent Pinchart <laurent.pinch...@ideasonboard.com> wrote: > > In that case the corruption probably happens on the camera > side. Have you > enabled the UVC_TRACE_FRAME trace level ? If so, do you get > any "Dropping > payload (error bit set)" message being printed to the > kernel log ? > When I enable UVC_TRACE_FRAME, I get a lot of these: uvcvideo: Dropping payload (out of sync).
And of course sometimes these: uvcvideo: Frame complete (EOF found). And very rarely this: uvcvideo: USB isochronous frame lost (-70). Interestingly, if syslogd is active along with the tracing, then I see no corrupted frames. However, if I disable syslog and just extract the log from dmesg, then the corruption is present. The logged messages are the same in both cases. This behavior is consistent with what I've seen before (more CPU available yields more corruption) and what leads me to suspect a cache aliasing/coherency issue. Also, the two cameras I have seen this corruption with use different ASICs (SPCA2211 and PAC7332), so that is the reason I am leaning towards the platform rather than camera-side corruption. I have ordered a camera which uses the gspca driver (Logitech QuickCam Communicate STX), so hopefully that should give me something to compare against. The gscpa maintainer long ago noted memory corruption on ARM platforms (http://sourceforge.net/mailarchive/forum.php?thread_name=200512301104.13088.mxhaard%40magic.fr&forum_name=spca50x-devs), so maybe he will have some insight. Regards, Filter _______________________________________________ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
