Re: [PATCH v3] printk: fix zero-valued printk timestamps in early boot

[Steven Rostedt <rostedt@goodmis.org>]

On Wed, 01 Apr 2026 10:33:26 +0200
Thomas Gleixner <tglx@kernel.org> wrote:

> Steven!
> 
> On Tue, Mar 31 2026 at 20:05, Steven Rostedt wrote:
> > On Wed, 01 Apr 2026 01:36:26 +0200
> > Thomas Gleixner <tglx@kernel.org> wrote:  
> >> That's ~12ms of time which is not accounted for in the overall boot time
> >> until the machine reaches the init process:
> >> 
> >> [   12.289141] Run /init as init process  
> >
> > 12 seconds! Holly crap, that would fail every Chromebook requirement we
> > have. In most cases, we shoot for a 3 second boot up and 8 second max.
> > That's from hitting the power button to login screen. FYI, 30ms is
> > considered a really long time.  
> 
> Which 30ms are you talking about?

Sorry, that was from your previous email:

   The existing early TSC enablement on x86 starts providing printk
   timestamps at about 30ms after boot out of the box when I remove
   'earlyprintk' from the command line on the same VM/host combo I tested
   the PoC. That too uses sched clock and not some special mechanism.

We actually try to account for pretty much every 10ms and if there's a 30ms
gap somewhere, we look to see what it was doing.

> 
> As I've demonstrated the time until the first time stamp is available
> has nothing to do with the number of CPUs and is more or less constant:

So my question is, if something changes in this time frame, where it goes
from 30ms to 300ms, how would we find out?

Again, for Chromebooks, we get these timestamps from the firmware and it's
very useful.

-- Steve