Re: CX18 Oops

[Andy Walls <awalls@radix.net>]

On Thu, 2008-08-07 at 09:36 -0400, Brandon Jenkins wrote:
> On Wed, Aug 6, 2008 at 8:55 PM, Andy Walls <awalls@radix.net> wrote:

> > from the offending build to me.  That way I can see the assembled
> > machine code and verify where in the function the NULL dereference is
> > happening.
> >
> > If you have the exact same problem as me, I can give you a "band-aid"
> > patch which will lessen the problem in short order.  It'll be a band aid
> > because it won't fix the accounting problem though.  I need to do more
> > extensive test and debug to find out where the accounting of buffers is
> > getting screwed up.
> >
> > Regards,
> > Andy

Brandon,

I have checked in a fix to defend against the Ooops we both encountered.
The fix will also generate a WARN dump and some queue stats when it runs
across the cause, but will otherwise try to clean up as best it can to
allow further operation.

The band-aid fix is the latest change at 

http://linuxtv.org/hg/~awalls/v4l-dvb

Please provide the extra debug that happens if you encounter the warning
in your logs.  I have only encountered the problem twice over a several
month period, so its hard to get insight into the root cause buffer
accounting error at that rate.


Hans,

The provided patch is a bit ugly, so I'm not sure I want it to go to the
main repo as is.  Since the cx18_queue_move() and cx18_queue_move_buf()
functions are a bit general for how cx18 is using them (compared to
ivtv) and a bit confusing at first, I was going to rewrite them down to
the minimum needed for cx18.  Do you have any objection?

I normally like the fact that cx18 mirrors ivtv in many aspects as it
provides an certain economy for common bug fixes.  Here I think cx18 is
carrying complexity and unused code (and maybe bugs) for only that
reason.

Regards,
Andy

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list