On Friday 08 August 2008 16:18:28 Andy Walls wrote:
> On Thu, 2008-08-07 at 09:36 -0400, Brandon Jenkins wrote:
> > On Wed, Aug 6, 2008 at 8:55 PM, Andy Walls <[EMAIL PROTECTED]> 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?
No objection at all. If you look at where cx18_queue_move is used, then
you'll notice that it is only in cx18_flush_queues(). And all it has to
do there is to move any buffers in the q_io or q_full queue to the
q_free queue and initialize all those buffers to their initial state.
You do not need all that complicated code for that. I suggest that you
make a new function instead that replaces cx18_queue_move and
cx18_queue_move_buf.
> 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.
Definitely. These two functions should be replaced for the cx18.
Regards,
Hans
_______________________________________________
ivtv-devel mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-devel
