[mythtv-users] Heavy load troubles

[Brian Foddy]

On Tuesday 23 December 2003 08:55 pm, Brian Foddy wrote:
> 1.  With all 3 cards recording, the PVR recording will
> frequently stop at some random time into the recording; say 6
> minutes into a 30 minute show.  The other recordings continue.
> The interesting thing is many times the pvr card
> recording before it stops, the audio will start getting
> progressively ahead (yes ahead) of the video, perhaps
> 1 second.  It doesn't seem to help if I reduce the
> recording quality settings.  There is no error messages
> in syslog or the backend that correspond to where it stops.
>
> 2.  At the end of the recording period above, the backend
> will almost always miss the next recording program completely,
> if its 1,2, or 3 shows.  It just never starts to record.
> If I restart the backend, it will then pick up recording
> where it should until the next 3-way.  The backend log
> shows:
> 2003-12-23 18:00:00 Changing from RecordingOnly to None
> 2003-12-23 18:00:00 Changing from RecordingOnly to None
> 2003-12-23 18:00:00 Changing from RecordingOnly to None
> 2003-12-23 18:00:01 Found changes in the todo list.
> But there should be more shows at 18:00 to record, no startup.
> There have been other times when it misses a recording,
> but never so consistantly as this.
>
> 3.  The software encoded recordings can have occasional
> audio/video stutters or repeats.  The stutter is in the recording,
> not in playback because if I rewind it stutters every time
> at the same point.  It affects both cards at the same time.
> There are 2 related log messages:
> /var/log/syslog shows:
> Dec 23 17:43:26 silver kernel: bttv1: irq: SCERR risc_count=36df2008
> Dec 23 17:45:53 silver kernel: bttv1: irq: SCERR risc_count=36df2008
> Dec 23 17:45:53 silver kernel: bttv1: aiee: error loops
> Dec 23 17:45:53 silver kernel: bttv0: irq: SCERR risc_count=36df2808
> Dec 23 17:45:53 silver kernel: bttv1: resetting chip
> Dec 23 17:45:53 silver kernel: bttv1: PLL can sleep, using XTAL (28636363).
>
> and backend log shows:
> VIDIOCSYNC: Input/output error
> VIDIOCSYNC: Input/output error
> VIDIOCSYNC: Input/output error
> VIDIOCSYNC: Input/output error
>
> So far, I have not confirmed any firm correlation between this
> problem and number 1 by time, other than its typical with 3 cards.
> ie:  tonight the pvr stopped at 17:32 but nothing like these messages
> at that time.
>

After some more debugging, I've found a relationship between
item 1 and 3 above.  Turning on the ivtv debug option, I found
the following pattern always occurs when the ivtv device stops:

Dec 24 21:55:18 silver kernel: ivtv: Sched DMA tasklet
Dec 24 21:55:18 silver kernel: ivtv: DMA/MPG type 0x00000000,size 
0x00003800,offset 0x00146adc
Dec 24 21:55:18 silver kernel: ivtv: size: 14336 0x00003800
Dec 24 21:55:18 silver kernel: ivtv: SGarray[0]: 0x00146adc, 0x32f80000 
0x80003800
Dec 24 21:55:18 silver kernel: ivtv: Sched dma: addr: 0x0702a000, array_size 
0x0000000c, type 0x00000000
Dec 24 21:55:18 silver kernel: bttv1: irq: SCERR risc_count=36df6008
Dec 24 21:55:18 silver kernel: bttv0: irq: SCERR risc_count=36df6808
Dec 24 21:55:18 silver kernel: bttv1: irq: SCERR risc_count=36df6010
Dec 24 21:55:18 silver kernel: bttv1: aiee: error loops
Dec 24 21:55:18 silver kernel: bttv1: irq: SCERR risc_count=36cd4014
Dec 24 21:55:18 silver kernel: bttv1: aiee: error loops
Dec 24 21:55:18 silver kernel: bttv1: resetting chip
Dec 24 21:55:18 silver kernel: bttv1: PLL can sleep, using XTAL (28636363).
Dec 24 21:55:18 silver kernel: bttv0: irq: SCERR risc_count=36df6808
Dec 24 21:55:18 silver kernel: bttv0: irq: SCERR risc_count=36df6808
Dec 24 21:55:18 silver kernel: ivtv: DeQ test from empty list!
Dec 24 21:55:47 silver last message repeated 290 times


Its always bttv1 that errors first, and bttv1 is on IRQ9 shared
with ivtv.  What I don't know is if the Sched dma is causing the
bttv1 error, or if the bttv1 error comes first causing the dma
to not complete; I'm guessing the latter.

Brian