The date on my x86 machine is going crazy. When I boot, it's in 1980 (as expected since the CMOS battery is dead). So I NTP sync it with no problems. Some time later (within a few hours, and even within minutes at times), the system ends up around one of the following dates:

Jun 09 00:21:48 UTC 2013  (Just a few days ago...)
Jan 30 14:14:06 UTC 2040  (Back to the future!)
Mar 08 00:08:31 UTC 2105  (Super far into the future)

I don't think NTP is doing this, as I only run 1-time NTP force updates (when it's not in the lab, NTP is not an option).

As near as I can tell, there is nothing special about any of these dates in either GPS or UTC time. Do these dates stand out to anyone as near the default if I overflow some particular format? Both future dates are beyond 2038 meltdown.

Specifics: this is an embedded system with an x86 board running QNX 6.4.1. It's using UTC time, with no timezone offset.

The date staying stable is pretty important. If it's just this particular system that is bad, fine, bad hardware or whatever. But if it's systemic, I need to isolate it and fix it.

What steps can I take to isolate this? Can someone please point me in the right direction?

Note: If this isn't the right forum for a question of this sort, please help me find the right one.

  • Can't. It's an embedded system. But the 1980 thing isn't a problem. That happens all the time with these older systems. It's the jumping around after I set the time that matters. – kmort Jun 13 '13 at 14:23
  • Look at all your programs running and see if any of those can change the time besides NTP. Check the logs of those programs to see if anything is going funky. Next check dmesg for any errors possibly causing the time to shift. – Wolfizen Jun 13 '13 at 14:26
  • slogger (dmesg equivalent) shows nothing that looks out of order. – kmort Jun 14 '13 at 11:33

While not a good answer for the general case, I'll close the loop.

This embedded system generally syncs with the GPS time from a hardware device. The firmware on the hardware device had been modified slightly when the digital folks went to a new version of the VHDL toolset. Long story short, the firmware was actually giving us crazy values to sync to, and the software was behaving "reasonably".

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.