> Yes... I cloned today's master branch, including your changeset cited above.
> I was sure to do 'make rminstall' in an older tree, to remove all traces of
> the older video_buf module before installing the new modules.
I suspect that there's a race condition related with the way we do mmap. I
got a similar issue with MSI TV @nyware AD NB (saa7134) and a dual core
AMD 64 notebook. The same device on a single core notebook works like a
charm. I had this trouble with both old and new videobuf.
I also noticed, on tm6000 driver, that, on my tests with newer kernels,
the calling order for file .mmap handler and videobuf_iolock has changed.
I did a workaround at videobuf-vmalloc for this case:
/* It seems that some kernel versions need to do remap *after*
the mmap() call
*/
if (mem->vma) {
I suspect that this bug happens on certain workloads, and depends on HZ
value.
Maybe adding a wait_event_timeout() will solve. I'll do some tests here.
--
Cheers,
Mauro
_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
