[vdr] PANIC: watchdog timer expired - exiting
Klaus.Schmidinger at cadsoft.de
Sun Dec 2 13:08:11 CET 2007
On 06/09/07 21:40, Petri Hintukainen wrote:
> On Sat, 2007-06-09 at 12:28 +0200, Udo Richter wrote:
>> And, from the original post:
>>> May 31 20:23:38 localhost vdr:  System Time = Thu May 31 20:23:38 2007 (1180632218)
>>> May 31 20:23:38 localhost vdr:  Local Time = Thu May 31 20:19:37 2007 (1180631977)
>>> May 31 20:21:01 localhost vdr:  PANIC: watchdog timer expired - exiting!
> Turning clock is always very bad and dangerous thing to do. It can cause
> lot of other problems too, just to mention incomplete builds, duplicate
> cron jobs, destroyed logs and files, incomplete backups ...
>> The clock was set to 20:19:37, and the watchdog fires at 20:21:01 - 84
>> seconds later. There must be something different causing the watchdog to
> It might be even some plugin. All timeouts (cTimeMs, cCondVar,
> cCondWait) use current wall clock time to set the timeout.
> cCondWait c;
> If clock is turned 2 minutes back in middle of this, the code will wait
> 120100 ms instead of 100ms ... Might cause some quite weird problems.
> I belive there's no way to change pthread_..._timedwait functions, but
> cTimeMs can be changed to use monotonic timers instead of gettimeofday
> (patch attached).
I have (finally, sorry for the big delay) adopted this patch (in the
attached form) to fix a problem with SVDRP connections when the system
time is adjusted.
While testing this, I found that on my system the monotonic clock
only has a resolution of 4000250 ns (about 4 ms), which in your original
patch would have caused VDR not to use the monotonic clock.
Are there actually systems that have a 1 ms resolution?
Or is there some parameter that needs to be adjusted to get a better
Maybe we should set the limit to, say, 10 ms, so that systems like
mine can also benefit from this. After all, the advantage of having
a monotonous clock outweighs the courser resolution (typically such
timeouts are not below 10 ms).
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 1969 bytes
Desc: not available
Url : http://www.linuxtv.org/pipermail/vdr/attachments/20071202/10e28f0f/attachment.bin
More information about the vdr