On Sunday 23 March 2008 03:27:56 Andy Walls wrote:
> On Fri, 2008-03-21 at 22:04 -0400, Andy Walls wrote:
> > On Sun, 2008-03-09 at 16:28 -0400, Andy Walls wrote:
> > > Hans Verkuil wrote:
> > > > On Sunday 09 March 2008 05:37:04 Andy Walls wrote:
> > > > > Hans Verkuil wrote:
> > > > > > > Here's my observation: There was no good reason for
> > > > > > > q_full to stay empty for so long (> 5 seconds), just
> > > > > > > because data was sitting queued in q_io. It was as if
> > > > > > > data stopped being moved from the encoder to buffers and
> > > > > > > into q_full. What is both fortunate and unfortunate is
> > > > > > > that draining q_full and q_io,
> > > >
> > > > seems
> > > >
> > > > > > > to restart the transfers from the encoder.
> > > > >
> > > > > Argh. I'm giving up on hunting this down for now. Here are
> > > > > my observations and speculations with the return value of
> > > > > cx18_v4l2_enc_poll() does not depend on q_io.length:
> > > > >
> > > > > a) The most buffers I've ever seen in use in the driver are 1
> > > > > in
> > > >
> > > > q_io
> > > >
> > > > > and 10 in q_full. That was when then encoder decided to give
> > > > > the driver 10 buffers all at once.
> > > > >
> > > > >
> > > > > b) I can always get the transfer from the encoder to stall.
> > > > >
> > > > > c) stopping the capture, reloading all the MDLs and
> > > > > restarting the capture doesn't make transfers from the
> > > > > encoder work again.
> > > > >
> > > > > d) a common sequence of failure looked like the following,
> > > > > with the encoder sending a small (2048 bytes) buffer, the
> > > > > driver returning 2 MDLs very close together, and then the
> > > > > encoder sending only one more buffer:
> > > >
> > > > ...
> > > >
> > > > > I changed the cx18_read() function to exit the loop and
> > > > > return once it had returned 1 MDL to the encoder, but the
> > > > > problem still persisted. In this case the short buffer in at
> > > > > least one trial was 4096 bytes.
> > > >
> > > > Is it possible to reproduce it by writing a small capture
> > > > program that
> > > > acts similar to MythTV? If I had a program like this, then I
> > > > could investigate.
> > >
> > > Yes, if I have time, I can write a program to emulate the
> > > critical aspects of MythTV's operation. You will have to back
> > > out the fix to cx18_v4l2_enc_poll() to purposely induce the
> > > stall. Also tuning to a weak, snowy channel (but not all snow)
> > > and changing channels will induce the problem more rapidly. I
> > > assume the encoder can't compress as well under these
> > > circumstances, so it sends more data to the host.
> >
> > Hans,
> >
> > Attached is the test program for which you asked. With it, you
> > should be able to reproduce select() timeouts with
> > cx18_v4l2_enc_poll() modified to not watch q_io. So you can at
> > least get the encoder transfers to stall for 5 seconds.
> >
> > I have not been able to get the test program to stall the encoder
> > transfers long term yet. I'll have to make it more MythTV-like, I
> > guess, by calling some of the ioctls that MythTV does.
>
> Hans,
>
> Attached is an updated version of the test program that sets up the
> device with ioctl()s as MythTV would. The item that made the
> difference on reproducing the "permanent" stall was the setup_vbi()
> function.
Thanks Andy,
I can reproduce it but it is not entirely clear what is going on. It
looks like a buffer that isn't thrown back into the MDL pool fast
enough. Or something like that. To be continued.
BTW: check out my latest cx18 tree, apparently ATSC is now working
thanks to the hard work of Steve Toth.
Regards,
Hans
>
> Note that upon further investigation the encoder isn't completely
> non-responsive. After closing and reopening the stream, it will
> produce one transfer into q_full. If nothing drains off q_full/q_io
> after that, it will not produce another transfer until the stream is
> closed and reopened again. For the MythTV user experience, this
> amount to a black screen and repeated select timeouts.
>
> Again, the fix to cx18_v4l2_enc_poll() to watch q_io now masks this
> bug.
>
> Regards,
> Andy
_______________________________________________
ivtv-devel mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-devel
