[PATCH v2 3/4] printk: nbcon: move printk_delay to console emiting code

[Andrew Murray]

Hi Benedikt,

On Fri, 3 Jul 2026 at 15:56, Benedikt Spranger <b.spranger at linutronix.de> wrote:
>
> On Tue, 30 Jun 2026 17:35:59 +0100
> Andrew Murray <amurray at thegoodpenguin.co.uk> wrote:
>
> > The printk_delay and boot_delay features are helpful for debugging
> > as kernel output can be slowed down during boot allowing messages to
> > be seen before scrolling off the screen, or to correlate timing
> > between some physical event and console output.
> By now, it slows down the boot process, which is the handy part of that
> feature.
>
> > However, since the introduction of nbcon and the legacy printer thread
> > for PREEMPT_RT kernels, printk records are now emited to the console
> > asynchronously to the caller of printk. Thus, any printk delay added
> > by boot_delay/printk_delay continues to slow down the calling process
> > but may not have any impact to the rate in which records are emited
> > to the console.
> Using this feature to slow down the boot/suspend/resume process and
> implicit make printk() happen, is the usefull part of that feature.
> Imagine this sequence (which hit me on suspend/resume on i.MX after
> shutting down all secondary CPUs)
>
>   printk("A");
>   (do some stuff)
>   printk("B");
>   read from peripheral --> system got stuck here since peripheral was
>   not clocked or powered or both any more.
>
> The delay (and later on a ugly patch to make printk() synchrounous)
> helped to locate where the failed access happend. JTAG did not help,
> since the CPU got stuck --> no JTAG communication to that CPU.

I understand the use-case, you sprinkle printk's so you can find the
point where a read to a register causes the CPU to stop. This requires
that the printk happens before the read, and the output from the
printk is printed before the read.


>
> With your purposed change you *may* see "A", but never "B".
> Quite challenging...

At present you may see 'A' and you may see 'B'.

Prior to the changes in this patchset, and assuming an nbcon console
(which may not be your usecase, but is perhaps representative of
future use-cases), then the printk delay will always happen within the
call to printk (and always before emitting). However, depending on the
context, that printk call may return (and proceed to your CPU halting
register read), before the message is actually emitted to the console.
I.e. it's a race.

This series moves the delay to the emit side, as well as moving the
delay after the emit. Thus the calling code may make progress more
quickly, but depending on the context, it may also flush/emit before
returning from printk.

In my view, with or without this series, there are no guarantees that
you will see 'A' and 'B'. And in any case, achieving the functionality
for debugging required you to modify the printk anyway.


>
> So please leave the delay on the calling side - it is helpfull there.

If you want to ensure printk is synchronous, perhaps you could call
nbcon_cpu_emergency_enter() prior to your printk, or perhaps there are
already printk wrappers that do somthing similar whilst debugging?
Would that provide a more reliable way to guarantee output?

Thanks,

Andrew Murray

>
> Regards
>     Bene Spranger