[linux-dvb] CX18 Oops

Brandon Jenkins bcjenkins at tvwhere.com
Mon Aug 18 12:35:45 CEST 2008


On Sat, Aug 16, 2008 at 10:13 PM, Andy Walls <awalls at radix.net> wrote:
> On Mon, 2008-08-11 at 17:33 -0400, Brandon Jenkins wrote:
>> On Fri, Aug 8, 2008 at 10:18 AM, Andy Walls <awalls at radix.net> wrote:
>> > 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.
>>
>> Andy,
>>
>> I had an oops today, first one in a few days
>>
>> Brandon
>
> Brandon & Jeff,
>
> I have updated my repo at
>
> http://linuxtv.org/hg/~awalls/v4l-dvb
>
> with 3 changes:
>
> 1. Back out the original band aid fix
> 2. Simplify the queue flush routines (you will not see that oops again)
> 3. Fix the interrupt handler to obtain a queue lock (prevents queue
> corruption)
>
> >From most of the output you provided, it was pretty obvious that q_full
> was always claiming to have more buffers that it actually did.  I
> hypothesized this could come about at the end of a capture when the
> encoder hadn't really stopped transferring buffers yet (after we told it
> to stop) and then we try to clear q_full while the interrupt handler is
> still trying to add buffers.  This could happen because the interrupt
> handler never (ever) properly obtained a lock for manipulating the
> queues.  This could have been causing the queue corruption.
>
> Please test.  I need feedback that I haven't introduced a deadlock.
>
> It also appears that the last change requiring the interrupt handler to
> obtain a lock, completely mitigates me having to use the "-cache 8192"
> option to mplayer for digital captures, and greatly reduces the amount
> of cache I need to have mplayer use for analog captures.
>
[snip]

Andy,

I have update to the new code. Interestingly now I am getting audio
noises (chirping) while watching TV. Is there anything which has been
done that could affect sound?

Otherwise no issues thus far.

Brandon



More information about the linux-dvb mailing list