On Mon, Nov 05, 2012 at 05:09:13PM +0100, Stanislav Meduna wrote:

On 05.11.2012 14:46, Shawn Guo wrote:

quoted

quoted

quoted

From my quick testing on imx23 with printk timestamp, it's not OK,
so we may need to leave imx23 out there.

I should say it's practically not OK since it wraps in such a short
period.  But it actually works as expected.

quoted

Hmm, does it wrap after 2 seconds?

Yes, it does wrap after ~2 seconds.

This is weird. AFAIK the printk should be using sched_clock(),
which is a weak symbol overridden in arch/arm/kernel/sched_clock.c
and it should take care of the extension to never-ever-wrapping
64-bit timestamp. Looks that it does not and if it does not,
I think there is more to be worried of than just printk timestamps.

It most certainly does handle the wrapping correctly - it was designed
to from the very start.

BTW this patch deserves IMHO looking at
  https://patchwork.kernel.org/patch/1193631/
but it is probably not the problem here.

Yes, that patch is probably required... if an update to the sched_clock
epoch happens on a different CPU, then the epoch cycles can be in advance
of the read clock cycle value.  That needs to get into my patch system.