On 10/18/2011 11:55 AM, David C. Rankin wrote:
Guys,
Here is one for the brain-trust to consider. Something totally screwed up the
time on my computer during an apcupsd commanded shutdown and the subsequent
reboot resulting in a 479 Minute time disparity. I don't think this was
handled on the first reboot after the power outage because after reboot, I
worked for 20-30 minutes before the OS imploded rebooted automatically. I
suspect the time discrepancy somehow carried through the boot and went along
until some kernel mechanism totally went bonkers and shut the system down.
<snip>
I don't have a clue what could have caused this time shift unless it was some
spurious voltage issue. If not, then something is definitely funny with the
time handling in either apcupsd or rtkit.
What say the experts, problem or just weird voltage induced time skew?
I think I have found part of the problem, but I cannot explain why the
hwclock wasn't in sync with the sysclock. The box has now rebooted 4 more
times, each time there is a time discrepancy of ~479 minutes.
[15:06 providence:/home/david] # grep disparity /var/log/everything.log
Oct 18 09:44:01 providence crond[953]: time disparity of -478 minutes detected
Oct 18 11:19:01 providence crond[978]: time disparity of -479 minutes detected
Oct 18 12:32:00 providence crond[1180]: time disparity of -479 minutes detected
Oct 18 12:42:00 providence crond[958]: time disparity of -479 minutes detected
hwclock was way out:
[14:44 providence:/home/david] # hwclock -r
Tue 18 Oct 2011 10:44:19 PM CDT -0.436795 seconds
huh???
[14:44 providence:/home/david] # hwclock -w
[14:44 providence:/home/david] # hwclock -r
Tue 18 Oct 2011 02:44:52 PM CDT -0.578618 seconds
I don't recall the specifics, but I recall a discussion about a change in
the way the OS keeps the hwclock in sync. I could be way off, but doesn't Arch
maintain the hwclock with --systohc?
With ntp running the sysclock was always correct after it synced, but for
some reason, the hwclock had drifted out of sync by this much? Granted, this
box usually runs from kernel update to kernel update without a reboot, but
still is it normal to accumulate that much hwclock drift?
I have checked 5 other Arch boxes and 4 were fine, but I have found another
with a hwclock issue:
date && sudo hwclock -r
Tue Oct 18 14:58:24 CDT 2011
Tue Oct 18 23:58:00 2011 -0.438598 seconds
Of the 6 boxes checked, 3 were Dell's and 2 out of 3 Dells had the hardware
clock skew. I don't know what to make of it. Bad hardware? Anybody else seeing
anything like this?
Sorry for the noise, but if this is something other than an "idiot, check
your hwclock in the BIOS issue.." I would welcome any other thoughts or
proposed checks. Thanks.
--
David C. Rankin, J.D.,P.E.
