Date/Time wildly jumping forward 2^17 seconds every few seconds/minutes

Hello,

I am watching this thread closely. I am not getting the feeling that this issue has been resolved. Does anyone believe that this issue has been resolved? Are you using work-arounds instead?

We, too, are experiencing random “time jumps”. Whenever our Beaglebone jumps ahead in time, we drop CAN frames. We have a test setup where we are constantly logging CAN frames to test for data loss (CAN drops), and unfortunately, we are dropping frames on occasion. Those drops align very well with jumps ahead in system time.

Our configuration:

  • Beaglebone, Rev A6
  • Kernel: 3.2.42-psp27
  • Distro: Ubuntu 12.10

I have tried applying a uboot update that Robert Nelson suggested in another thread related to this, and I just recently applied the patch attached to this thread. The uboot update did not work, and we have not been running long enough to provide any guidance on whether the timer errata patch is effective; although, I am not feeling very confident about it.

I would love to hear back from others who are suffering from this problem.

Thanks.

Ahh... How old was that u-boot update that i mentioned? As i just
pushed out v2013.04 two weeks ago, and things are starting to assume
that version going forward... :wink:

Regards,

You mentioned it in the thread here (Dec, 2012):

https://groups.google.com/forum/?fromgroups=#!topic/beagleboard/j4fdat3Bj04

I did a netinstall back in early April. Uboot updated about a week ago. Either way, I don’t think having the uboot fix had any bearing on this problem. I knew it was stretch going in; but I thought it was worth a try.

Brock

I have confirmed that even with the patch mentioned in this thread, our clock still jumps ahead. Did a few times over the weekend.

One interesting note: The problem seems to be isolated to one board. We have 3-4 boards running and logging time on a regular basis just to see if the time ever jumps. We only get the problem on the board that is logging CAN data.

I plan to roll up the sleeves and dig into this. It sure would be nice to output some extra debug information associated with clock_gettime() or the registers/variables that are holding timer counts. Anyone have any suggestions on where to start?

Thanks.

I have confirmed that even with the patch mentioned in this thread, our
clock still jumps ahead. Did a few times over the weekend.

One interesting note: The problem seems to be isolated to one board. We
have 3-4 boards running and logging time on a regular basis just to see
if
the time ever jumps. We only get the problem on the board that is logging
CAN data.

How do you log CAN data? Via the am335x CAN interface or some other
way?

I plan to roll up the sleeves and dig into this. It sure would be nice to
output some extra debug information associated with clock_gettime() or
the
registers/variables that are holding timer counts. Anyone have any
suggestions on where to start?

Last night I ran all night on one white bone calling time(NULL) as fast
as possible looking for a time jump but I was not successful. In the
situations where my bones jump time, time(NULL) gets called about once
every millisecond so it seems like the root cause.

This afternoon, I've enabled NTP and Ethernet on that bone and have
started running again. It's been hours so far and no luck yet
recreating the problem. If this doesn't work, I'll be connecting our
custom cape and putting a load on the system that way in addition to
calling time(NULL) as fast as possible.

Does anyone have a set of test code that can cause this to happen
reasonably quickly?

Thanks,
Andrew

can you register over on http://bugs.elinux.org and file a bug report on this?

Dave

can you register over on http://bugs.elinux.org and file a bug report on
this?

Yes.

http://bugs.elinux.org/issues/15

Thanks,
Andrew

I think I'm having the same problems. Probably. I haven't tried the patch.
I make clock_gettime() calls (about 3-4 per minute), but I also nanosleep
pretty continually, which sounds like it might use related stuff.

The only odd thing I have to add is that in my case, ntpd doesn't freak out
and die, but keep going. The ntpd program shows up in top like this:

466 ? Ss 1:26 /usr/bin/ntpd -p /var/run/ntp.pid -g

Presumably its the -g option that keeps it alive. It seems that ntpd does
ultimately drag the clock back to accurate. But my logged data shows that
the clock is frequently way off for long periods, which isn't surprising since
if I understand correctly ntpd adjust things only by slewing the clock rate,
rather than resetting anything (and producing a discontinuity in the clock).

I guess the only known workaround at the moment is to run some code that
watches for these discontinuities, and kill ntpd, and rerun ntpdate when
they occur?

Has anyone ever observed this issue on BBB, or on a BBW running 3.8?

Britton

On further investigation... it was all my fault in this case. I may
have the time
warp problem others have encountered, but I have no evidence of it yet.

Britton

Hi all,

I’m working on a custom board and this problem always happens. Few minutes after system boots, its date starts to jump forward 2^17 seconds.

The hwclock is ok, but date is not.

I applied the kernel patch, but no difference.

Maybe my system could help you to find the bug.

Thank’s
Andre