Re: CX18 Oops

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Aug 18, 2008 at 6:35 AM, Brandon Jenkins <bcjenkins@xxxxxxxxxxx> wrote:
> On Sat, Aug 16, 2008 at 10:13 PM, Andy Walls <awalls@xxxxxxxxx> 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@xxxxxxxxx> 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
>
Andy,

I also seeing these messages in dmesg:

[65288.817420] cx18-0: Cannot find buffer 58 for stream TS
[65288.817440] cx18-0: Could not find buf 58 for stream TS
[65840.130797] cx18-0: Cannot find buffer 17 for stream TS
[65840.130797] cx18-0: Could not find buf 17 for stream TS
[65861.882721] cx18-0: Cannot find buffer 48 for stream TS
[65861.882741] cx18-0: Could not find buf 48 for stream TS
[66151.627392] cx18-0: Cannot find buffer 107 for stream encoder MPEG
[66151.627392] cx18-0: Could not find buf 107 for stream encoder MPEG
[67632.953680] cx18-0: Cannot find buffer 99 for stream encoder MPEG
[67632.953680] cx18-0: Could not find buf 99 for stream encoder MPEG
[67795.527911] cx18-0: Cannot find buffer 106 for stream encoder MPEG
[67795.527911] cx18-0: Could not find buf 106 for stream encoder MPEG

Brandon

_______________________________________________
linux-dvb mailing list
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

[Index of Archives]     [Linux Media]     [Video 4 Linux]     [Asterisk]     [Samba]     [Xorg]     [Xfree86]     [Linux USB]

  Powered by Linux