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

Hi John,

On 25/08/2026 23:02, John Ogness wrote:

...

> Your results surprise me a bit because in previous attempts it seemed
> you were also getting hangs related to printk's not produced within
> cpuidle. This would lead me to believe that cpuidle is entered while
> irq_work from a directly preceeding printk (from outside cpuidle) was
> pending and caused a problem.
> 
> Does this hack really work reliably, without using keep_bootcon or any
> other patches?

I went back and started again on top of next-20260825.

Vanilla next-20260825 is failing on Tegra20 about 19 boots out of 20.
With hack 1 and hack 2 it is also pretty much 100% failure with 20
boots. However, with the latest hack it is passing 100% (20 out of
20 boots). So yes I say that this works reliably.

> Also, although this hack will avoid queuing irq_work from within
> cpuidle, it does not prevent the 8250 console driver from queuing
> irq_work for MSR handling during atomic printing. There is no generic
> console callback to deal with that (other than suspending the console).
> 
> I suspect it is a general irq_work problem on tegra regarding
> suspend/cpuidle. Really the problem should be fixed there. But I would
> need hardware to investigate the issue.

I am seeing this on Tegra20 and Tegra30 boards, which are the oldest we
test and so difficult to get hardware for these.

So there is the following code in the cpuidle-tegra.c driver ...

  if (tegra_pending_sgi()) {
         /*
          * CPU got local interrupt that will be lost after GIC's
          * shutdown because GIC driver doesn't save/restore the
          * pending SGI state across CPU cluster PM.  Abort and retry
          * next time.
          */
          atomic_set(&tegra_abort_flag, 1);
}

So may be interrupts are getting lost?
  
> As for this 8250 "switch to nbcon" series, I am uncertain how to
> proceed. Is it really printk's job (and, by extension, the console
> driver's job) to decipher when it is allowed to queue irq_work?
Yes understand. I am not sure if it is possible to opt out of this
switch for old legacy platforms like this?

Jon

-- 
nvpublic