4

We have custom hardware running 3.2 Angstrom on a SAM9G45 processor. Everything works fine. Recently we designed similar hardware that uses the SAM9G25 processor. We found the 2.6 kernel works fine on the SAM9G25, but we needed to port the 3.2 kernel to the platform to take advatage of some wireless drivers. We completed the port, but we have just discovered the time of day clock is not reliable. It runs fine for about 20 minutes - then the time (reported by "date") will jump ahead a few hours or days. The 2.6 kernel still works fine, so we think it's something we did not port correctly. We have looked over everything, but no luck so far. I'm not sure where to look next.

Final Answer: Atmel supplies a patch for the 2.6 kernel, to the file tcb_clksrc.c. We missed that in our port to the 3.2 kernel. Thanks for the insight!

Jeff
  • 701
  • 1
  • 6
  • 13

1 Answers1

2

Try booting the system with the kernel-option clocksource=jiffies or nohpet.

I have an open case about SLES11 SP2 (using Kernel 3.0) where I observe time-mismatches on VMs.

The clocksource=jiffies made it worse in my case - but in yours it might help.

Currently the support is focussing on the high-precision-event-timer (but I doubt that your embedded system has such a device).

Nils
  • 18,202
  • 11
  • 46
  • 82
  • If possible, you want your guests to use a para-virtualised clock (e.g., CONFIG_KVM_CLOCK). – derobert Oct 05 '12 at 15:25
  • Thanks for the insight. The clock=jiffies did work for me as a workaround. The actual answer is we missed an Atmel supplied patch for the 2.6 kernel that patched the tcb_clksrc.c for the SAM9X5 processors. Just too tired to see it last night, but now it's pretty obvious. – Jeff Oct 05 '12 at 16:24
  • @derobert the case is with PV-XEN-DomUs. – Nils Oct 05 '12 at 17:55
  • @Jeff and the same patch works for the 3.2-kernel? – Nils Oct 05 '12 at 17:56
  • @Nils - yes just finished initial testing, took about 20 minutes to demonstrate the original problem – Jeff Oct 05 '12 at 18:02
  • @Jeff Is [this](http://lists.infradead.org/pipermail/linux-arm-kernel/2012-January/081087.html) the patch? But this is just using a 32-bit instead of two 16-bit-counters - how does this help? – Nils Oct 05 '12 at 20:55
  • @Nils The G25 does not have two 16 bit counters, only one. The other counter register seems to add some increment after 20 minutes or so. So the patch avoids reading the other counter. The G45 does have both counters. – Jeff Oct 06 '12 at 13:59
  • @Jeff you should probably post your comments about the patch as an answer, in case anyone else using a G25 stumbles across this question. – derobert Oct 08 '12 at 14:07