Re: [PATCH tty v11 1/2] serial: 8250: Switch to nbcon console, take 2

Re: [PATCH tty v11 1/2] serial: 8250: Switch to nbcon console, take 2

[Jon Hunter]

Hi John,

On 29/07/2026 13:04, John Ogness wrote:
> Implement the necessary callbacks to switch the 8250 console driver
> to perform as an nbcon console.
> 
> Add implementations for the nbcon console callbacks:
> 
>    ->write_atomic()
>    ->write_thread()
>    ->device_lock()
>    ->device_unlock()
> 
> and add CON_NBCON to the initial @flags.
> 
> All hardware access in the callbacks is within unsafe sections.
> The ->write_atomic() and ->write_thread() callbacks allow safe
> handover/takeover per byte and add a preceding newline if they
> take over from another context mid-line.
> 
> For the ->write_atomic() callback, a new irq_work is used to defer
> modem control since it may be called from a context that does not
> allow waking up tasks. During suspend/resume the irq_work is not
> used as this has been shown to cause suspend problems for some
> hardware. Upon resume, any pending modem control is performed.
> 
> Note: A new __serial8250_clear_IER() is introduced for direct
> clearing of UART_IER during console writing (which will not be
> holding the port lock for atomic printing or KDB/KGDB). This
> allows restoring a lockdep check to serial8250_clear_IER() in
> a follow-up commit.
> 
> Signed-off-by: John Ogness <john.ogness@linutronix.de>

I accidently responded to V9, but responding here with the same report 
for completeness.

This change is causing a boot regression for our Tegra20 and Tegra30 
platforms. Reverting this on top of -next fixes the issue. Previously 
with V5 I did not see a boot issue only an issue in suspend. So far I 
have not had chance to dig any further.

Jon

-- 
nvpublic

Re: [PATCH tty v11 1/2] serial: 8250: Switch to nbcon console, take 2

[Sebastian Andrzej Siewior]

On 2026-08-18 07:25:13 [+0100], Jon Hunter wrote:
> Hi John,
Hi,

> This change is causing a boot regression for our Tegra20 and Tegra30
> platforms. Reverting this on top of -next fixes the issue. Previously with
> V5 I did not see a boot issue only an issue in suspend. So far I have not
> had chance to dig any further.

If my counting is correct: v5 is from last year
	https://lore.kernel.org/all/20250107212702.169493-1-john.ogness@linutronix.de/

and part of v6.14 however the nbcon bits itself were reverted before the
final release. That is why v6 till the applied v11 has only two
patches.

> Jon

Sebastian

Re: [PATCH tty v11 1/2] serial: 8250: Switch to nbcon console, take 2

[Petr Mladek]

On Tue 2026-08-18 07:25:13, Jon Hunter wrote:
> Hi John,
> 
> On 29/07/2026 13:04, John Ogness wrote:
> > Implement the necessary callbacks to switch the 8250 console driver
> > to perform as an nbcon console.
> > 
> > Add implementations for the nbcon console callbacks:
> > 
> >    ->write_atomic()
> >    ->write_thread()
> >    ->device_lock()
> >    ->device_unlock()
> > 
> > and add CON_NBCON to the initial @flags.
> > 
> > All hardware access in the callbacks is within unsafe sections.
> > The ->write_atomic() and ->write_thread() callbacks allow safe
> > handover/takeover per byte and add a preceding newline if they
> > take over from another context mid-line.
> > 
> > For the ->write_atomic() callback, a new irq_work is used to defer
> > modem control since it may be called from a context that does not
> > allow waking up tasks. During suspend/resume the irq_work is not
> > used as this has been shown to cause suspend problems for some
> > hardware. Upon resume, any pending modem control is performed.
> > 
> > Note: A new __serial8250_clear_IER() is introduced for direct
> > clearing of UART_IER during console writing (which will not be
> > holding the port lock for atomic printing or KDB/KGDB). This
> > allows restoring a lockdep check to serial8250_clear_IER() in
> > a follow-up commit.
> > 
> > Signed-off-by: John Ogness <john.ogness@linutronix.de>
> 
> I accidently responded to V9, but responding here with the same report for
> completeness.
> 
> This change is causing a boot regression for our Tegra20 and Tegra30
> platforms. Reverting this on top of -next fixes the issue. Previously with
> V5 I did not see a boot issue only an issue in suspend. So far I have not
> had chance to dig any further.

Interesting.

Another clue, mentioned in the v9 thread [1], is that the boot
regression does not happen with v11 when "keep_bootcon" option
is used.

The "keep_bootcon" option causes that the boot console driver stays
registered even when the full featured driver gets registered
later.

The most important effect is that the printk kthreads can't
be used as long as any boot console driver is registered.
All drivers need to be called in the legacy loop in this case.
There are two reasons for this:

  1. Boot console drivers are synchronized only by
     the legacy console_lock (console_sem). port->lock
     is available only for the full featured driver.

  2. There is no easy way to match boot console and
     full featured console drivers working on the same
     HW.

So, the regression seems to happen when the printk kthreads
start being used.

Jon, could you please share the full log when "keep_bootcon"
is used?

[1] https://lore.kernel.org/all/20260724103654.133654-1-john.ogness@linutronix.de/

Best Regards,
Petr

Re: [PATCH tty v11 1/2] serial: 8250: Switch to nbcon console, take 2

[Jon Hunter]

Hi Petr,

On 18/08/2026 08:51, Petr Mladek wrote:

...

>> This change is causing a boot regression for our Tegra20 and Tegra30
>> platforms. Reverting this on top of -next fixes the issue. Previously with
>> V5 I did not see a boot issue only an issue in suspend. So far I have not
>> had chance to dig any further.
> 
> Interesting.
> 
> Another clue, mentioned in the v9 thread [1], is that the boot
> regression does not happen with v11 when "keep_bootcon" option
> is used.
> 
> The "keep_bootcon" option causes that the boot console driver stays
> registered even when the full featured driver gets registered
> later.
> 
> The most important effect is that the printk kthreads can't
> be used as long as any boot console driver is registered.
> All drivers need to be called in the legacy loop in this case.
> There are two reasons for this:
> 
>    1. Boot console drivers are synchronized only by
>       the legacy console_lock (console_sem). port->lock
>       is available only for the full featured driver.
> 
>    2. There is no easy way to match boot console and
>       full featured console drivers working on the same
>       HW.
> 
> So, the regression seems to happen when the printk kthreads
> start being used.
> 
> Jon, could you please share the full log when "keep_bootcon"
> is used?


Yes absolutely. You can find the boot log here [0]. So far nothing 
really stands out to me but let me know if you see anything.

Jon

[0] https://pastebin.com/FhQVSqfy

-- 
nvpublic