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? 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 _______________________________________________ ivtv-devel mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-devel
