On Mon, Nov 05, 2012 at 05:09:13PM +0100, Stanislav Meduna wrote: > On 05.11.2012 14:46, Shawn Guo wrote: > > >>> 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. > > > >> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
