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
