[mythtv-users] Need help troubleshooting cause of DMA Timeouts

Craig Huff huffcslists at gmail.com
Thu Aug 25 00:27:29 UTC 2011


On Tue, Aug 23, 2011 at 6:48 PM, Craig Huff <huffcslists at gmail.com> wrote:
> I had a stable BE/FE running MythBuntu 10.04 on a single core Athlon
> 64 cpu and foolishly (or so it seems) decided to upgrade to a
> dual-core Athlon II cpu to enable more concurrent processing.  I can't
> see any reason why this would cause the problem I'm having, but
> nothing else has changed.
>
> Since then I randomly get system lockups where nothing can reach the
> backend process and/or the mysql service and yet the mouse and
> keyboard still get response, more promptly for the mouse, but still...
>  The only recourse seems to be to restart an undetermined number of
> processes or treat it like windoze and reboot.  Naturally the WAF is a
> little better using the sledgehammer approach ;-)
>
> When it acted up last night, these snippets are the closest I could
> find to a smoking gun:
>
> /var/log/syslog:
> ...
> Aug 22 21:35:01 penguin CRON[14069]: (mythtv) CMD (echo "`date +%r`:
> `sensors -f | grep 'CPU Temp'`" >> /var/tmp/temperature.log 2>&1)
> Aug 22 21:35:59 penguin kernel: [11811.996029] ivtv3: DMA TIMEOUT 00000001 2
> Aug 22 21:35:59 penguin kernel: [11812.296025] ivtv3: DMA TIMEOUT 00000001 0
> Aug 22 21:36:00 penguin kernel: [11812.596027] ivtv3: DMA TIMEOUT 00000001 2
> Aug 22 21:36:02 penguin kernel: [11815.164029] ivtv3: DMA TIMEOUT 00000001 2
> ...
>
> and /var/log/kern:
> Aug 22 18:20:45 penguin kernel: [   97.684037] Clocksource tsc
> unstable (delta = -148975716 ns)
> Aug 22 21:35:59 penguin kernel: [11811.996029] ivtv3: DMA TIMEOUT 00000001 2
> Aug 22 21:35:59 penguin kernel: [11812.296025] ivtv3: DMA TIMEOUT 00000001 0
> Aug 22 21:36:00 penguin kernel: [11812.596027] ivtv3: DMA TIMEOUT 00000001 2
> Aug 22 21:36:02 penguin kernel: [11815.164029] ivtv3: DMA TIMEOUT 00000001 2
>
> This latest flub, as usual was after a random period of minutes to
> hours after boot-up with no discernible pattern leading up to the
> lockup.  Also, the most recent recording start was over 35 minutes
> before the problem surfaced, and should have continued to the top of
> the next hour.  Can anyone suggest causes or things to look at?
>
> FWIW, I normally start commflagging immediately, but just recently
> changed it to wait until after the recording had finished -- didn't
> help.  Also, I have the commflag job "de-niced" to minimize I/O
> loading with a lowered ionice setting.  I can dig up the command
> string if someone thinks it might be a clue, but it has been that way
> for years.
>
> TIA,
> Craig.
>

Update:

Here's what I have for the commflagging command in the backend setup:
       ionice -n 7 nice -n 20 mythcommflag -j %JOBID% -V %VERBOSELEVEL%

Craig.


More information about the mythtv-users mailing list