On 12/14/12 16:11, A C wrote:
I finally had a panic stop with an instrumented copy of 4.2.7p270
which was capturing various values inside the functions
refclock_process_f and refclock_process_offset.
I'm going to post an entire capture of the log but one thing I noticed
is that the value of pp->nsec at the top of refclock_process_f slowly
ticks down and then wraps around. Eventually a panic stop happens:
panic_stop +2147483648 s; set clock manually within 1000 s.
(but the clock hasn't changed, the system time is still correct to
within a second of all my other systems).
Apparently the wrap around happens pretty frequently so it's not
likely the cause of the problem.
For now the log is available at http://acarver.net/ntpd/ntpd_panic.log
(8 MB file, be warned) in case any of you has an idea about what might
be happening to cause the panic or there's anything else I should
instrument and write to the logs instead. There are several steps in
each of the functions written out to the log looking for overflows or
similar. I do have various statistics files for that period, too, if
they would be useful.
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
Not know where how the executable was instrumented, it is hard to tell
exactly what all of this output means. But there is one thing that jumps
out at me. Exactly at the time that the panic stop occurs, ntpd has just
peered with the SHM refclock. This suggests that the time stored in
shared memory is either uninitialized or is the wrong format.
--
blu
Always code as if the guy who ends up maintaining your code will be a
violent psychopath who knows where you live. - Martin Golding
-----------------------------------------------------------------------|
Brian Utterback - Solaris RPE, Oracle Corporation.
Ph:603-262-3916, Em:brian.utterb...@oracle.com
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
