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.