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

Hi Petr,

On Fri, Apr 17, 2026 at 6:37=E2=80=AFAM Petr Mladek <[email protected]> wrot=
e:
>    2. The early timestamps provided by the bogo cycles
>       are not synchronized with timestamps from
>       the proper time keeping.
>
>       Would it help to print a disclaimer, similar to,
>       for example, trace_printk() first use?
>       Something like:
>
> [    0.002912] **********************************************************
> [    0.002917] ****   NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE
> [    0.002921] **
> [    0.002935] ** Using BOGO early timestamps
> [    0.002939] **
> [    0.002943] ** They are not properly calibrated and might use a source
> [    0.002949] ** with an unstable frequency.
> [    0.002953] **
> [    0.002957] ** They are not comparable with timestamps after
> [    0.002961] ** the timekeeping is initialized.
> [    0.002966] **
> [    0.002968] ****   NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE
> [    0.002971] *******************************************************
> [    0.002975] Booting Linux on physical CPU 0x0000000000 [0x410fd083]
> [    0.002998] Linux version 7.0.0-rc6-v8+ (tbird@timdesk) (aarch64-linux=
-gnu-gcc (Ubuntu 13.3.0-6ubuntu2~24.04) 13.3.0, GNU ld (GNU Binutils for Ub=
untu) 2.42) #20 SMP PREEMPT Fri Apr 10 11:57:48 MDT 2026
> [    0.003002] KASLR enabled
> [    0.003338] random: crng init done
> [    0.003866] Machine model: Raspberry Pi 4 Model B Rev 1.5
> [    0.004495] efi: UEFI not found.
> ...
> [    0.183552] Root IRQ handler: gic_handle_irq
> [    0.183561] GIC: Using split EOI/Deactivate mode
> [    0.183699] rcu: srcu_init: Setting srcu_struct sizes based on content=
ion.
> [    0.183958] clocksource: arch_sys_counter: mask: 0xffffffffffffff max_=
cycles: 0xc743ce346, max_idle_ns: 440795203123 ns
> [    0.183952] arch_timer: cp15 timer running at 54.00MHz (phys).
> [    0.183957] **********************************************************
> [    0.183962] ****   NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE
> [    0.183967] **
> [    0.183971] ** End of BOGO early timestamps
> [    0.183976] **
> [    0.183982] ****   NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE
> [    0.183989] **********************************************************
> [    0.000000] sched_clock: 56 bits at 54MHz, resolution 18ns, wraps ever=
y 4398046511102ns
> [    0.000157] Console: colour dummy device 80x25
> [    0.000165] printk: legacy console [tty1] enabled
>
> My view is that it would be nice to make the life easier
> for the 50 developers who do very useful work.
>
> But we do not need to create and maintain any complicated
> code for this. If the bogo cycles are good enough.
> If they already have some users and have to stay anyway.
> If we make it clear that the early timestamps are bogus...
>
> IMHO, the main risk is that it won't be used just by the 50 developers
> but it will get misused and open some can of worms. I think that
> the risk might be acceptable but...
>
> What do you think, please?
> Am I too naive in this case?

Thanks for the nice summary of the discussions so far. From the
standpoint of the boot speed work that I have done so far, the bogo
cycles would be good enough in my opinion. It would have identified
that I issue that I described earlier in this thread.

Regarding the message, I would put a firmer message similar to what's
in drivers/iommu/iommu-debugfs.c that also has this message:

    If you see this message and you are not debugging the kernel,
report this immediately to your vendor!

That way this is unlikely to be enabled in distro kernels.

Brian