Re: [PATCH v4 1/1] printk: fix zero-valued printk timestamps in early boot

[Roberto A. Foglietta]

On Tue, 21 Apr 2026 at 16:13, Bird, Tim <Tim.Bird@xxxxxxxx> wrote:
>
> > -----Original Message-----
> > From: Petr Mladek <pmladek@xxxxxxxx>
> > On Mon 2026-04-20 22:18:29, Bird, Tim wrote:

> > I think that we could print both notices from the printk() code:
> >
> >  + 1st one before the very first message
> >  + 2nd one before the first message with a proper timestamp from
> >    the local_clock().
>
> Yes.  That's a good solution.  I feel a bit dumb for not having thought of it. :-)

The very first message is when the kernel receive the hand off:

[    0.183957] Linux version 5.15.202 (roberto@x280) (x86_64-linux-musl-gcc
               (GCC) 14.3.0, GNU ld (GNU Binutils) 2.44) #1 Wed A6

The second one is when the skew happens

[    0.184241] kvm-clock: cpu 0, msr bac001, primary cpu clock
--------- time skew here ---------
[    0.000001] kvm-clock: using sched offset of 55985760 cycles

and also the second is already there: printed by kvm-clock about the
offset (3x the legacy rdtsc reading on a KVM machine, in my specific
case, at least).

[    0.000005] tsc: Detected 1896.002 MHz processor

Soon later another printk explains how to convert the early printk
timestamps into time, using the CPU clock. An information provided by
the tsc subsystem.

Everything was already there. Adding an how-to read data into Kconfig
description would impose the need to update that how-to and
differentiate it among arch/cases plus it might be wrong/useless when
working on an unsupported platforms or not a yet delivered products.
Moreover, it would put a burden on code janitors to explain stuff to
expert kernel hackers which is a non-sense role-inversion!

Therefore patch V6, again.

Best regards, R-