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: [3413] System Time = Thu May 31 20:23:38 2007 (1180632218) May 31 20:23:38 localhost vdr: [3413] Local Time = Thu May 31 20:19:37 2007 (1180631977) May 31 20:21:01 localhost vdr: [3405] 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 expire.
It might be even some plugin. All timeouts (cTimeMs, cCondVar, cCondWait) use current wall clock time to set the timeout. Example: cCondWait c; c.Wait(100);
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 resolution?
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).
Klaus