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

[Roberto A. Foglietta]

On Thu, 16 Apr 2026 at 01:12, Bird, Tim <Tim.Bird@xxxxxxxx> wrote:
>
> > -----Original Message-----
> > From: Roberto A. Foglietta <roberto.foglietta@xxxxxxxxx>
> > On Wed, 15 Apr 2026 at 23:57, Roberto A. Foglietta
> > <roberto.foglietta@xxxxxxxxx> wrote:
> > >
> >
> > [...]
> >
> > > V5
> > >
> > > A single file with the essential for hacking the early boot,
> >
> > early_times.h -- it means before every feature offered by the kernel
> > is available or 100% trustable, thus ASM because it is also supposed
> > to fix what is broken in the kernel thus using the kernel macros isn't
> > the correct way to do so. Early times means before the kernel, thus
> > also out-of-it-three or feature support. Them asm (isb) sounds too
> > drastic or not enough for "exhotic" arm arch? It is a template to
> > start with, not a working part of the kernel. When the kernel works,
> > !0 == true is true.
>
> Roberto,
>
> I appreciate your work to address deficiencies in the proposed
> patch, but I don't follow the above paragraph.  There's nothing
> "broken" about the kernel to fix, just an opportunity to
> instrument more code during bootup than is currently supported.
>
> I think Thomas has demonstrated that this does not have a lot of value
> for x86_64 platforms (where the blind spot is already quite small), but
> on ARM64 and RISCV I think there is some value to developers working
> on boot time.
>

My printouts about x86_64 confirmed, in such a platform the timekeeper
subsystem is almost instantaneously ready.


> > The concept remains the same: a register counter read protected by
> > fencing. Not more, not less than the essential. And a bucket
> > out-of-the-three as a starting point **before** the kernel is ready or
> > fixed. Written in this way, does it sound more reasonable?
>
> I don't know what "bucket out-of-the-three" means?

It is not clear to me what you are trying to achieve with V4 but that
patch was WRONG in principle, in concept and in implementation and
this sparked the debate, nothing else. Plus, there is no bug to fix,
apart from a regression that V4 would have introduced. The correct
approach is the V5 that I rewrote for you:

- https://raw.githubusercontent.com/robang74/uchaosys/e48de8fde/cnfg/printk-early-boot-timestamps-hack-v5.patch

That constitutes an entry point in which every developer can include
their own code. Please, follow that canvas especially if your company
is supporting your upstream campaign with a budget. So, lately your
code could silently be stripped away in favour of a more general
approach. ARM didn't arrive in Linux yesterday and I would be
surprised that you are trying to solve an issue that bothers a lot of
people. Anyway, I can be wrong, but 1700 ms to reach the internal
clock settings isn't sane.

The general approach is having an "early times" entry point in which
people that are porting the kernel on a new silicon can have a "ready
to go" way to start in dealing with printk (thus console output) and
timings (the two things need to start with) after they managed to
complete the boot (which isn't always granted and in some cases it is
a luxury not a commodity).

>
> Thomas has expressed concerns about a number of issues with the latest v4
> patch which I haven't responded to yet.  I was trying to reproduce the bug
> report with clang compilation (reported by 0-day on Sunday), and so far have
> not been able to. I have a proposed solution for that, and for other feedback received.
> But I hesitate to make a V5 patch before I reproduce the problem on my system
> and verify my fix for that bug report.

Please, also consider the feedback you received about 0-division: you
might have a problem sitting between the chair and the screen of your
system... ;-) LOL

Usually, we **humans developers** are such a problem >99.9% times when
gcc complains.

>
> Honestly, given how strongly Thomas feels about some of the items, this may end
> up not being accepted upstream.  But rather than give up at this point, I'd like to
> at least address all feedback received and issue one more patch for consideration.
> If it doesn't get accepted, I will have received some valuable feedback which will
> help make the (out-of-tree) patch as general and as conformant with kernel standards
> as possible, which is useful.

Take my V5 patch, apply (or adapt to apply if your kernel version
differs from 5.15) and then start to put your code into early-times.h
when you completed your investigation, you will appreciate the great
advantage of fix the problem with a single command line operation in
your local source tree: rm -f early-times.h

Best regards,

--
Roberto A. Foglietta
+49.176.274.75.661
+39.349.33.30.697