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

[Petr Mladek <pmladek@suse.com>]

On Wed 2026-08-26 00:08:46, John Ogness wrote:
> On 2026-08-25, Jon Hunter <jonathanh@nvidia.com> wrote:
> >>> With this I see a little more output on the console, but it still
> >>> appears to hang later and never fully boots.
> >>>
> >>> Boot log here: https://pastebin.com/Xe1vmeUj
> >> 
> >> Thanks, this information is helpful. Below is another hack, to be used
> >> on the unmodified linux-next. For whatever reason, I think the queuing
> >> of irqwork is causing problems. Perhaps the irqwork is actually firing
> >> even though interrupts are supposed to be disabled here.
> >> 
> >> The following hack will disable the queuing during the cpuidle. Please
> >> give this a try:
> >> 
> >> ===== BEGIN CPUIDLE HACK =====
> >> diff --git a/drivers/cpuidle/cpuidle-tegra.c b/drivers/cpuidle/cpuidle-tegra.c
> >> index aca907a62bb5d..1dca9d6defbff 100644
> >> --- a/drivers/cpuidle/cpuidle-tegra.c
> >> +++ b/drivers/cpuidle/cpuidle-tegra.c
> >> @@ -226,6 +226,7 @@ static int tegra_cpuidle_adjust_state_index(int index, unsigned int cpu)
> >>   	return index;
> >>   }
> >>   
> >> +extern bool console_irqwork_blocked;
> >>   static __cpuidle int tegra_cpuidle_enter(struct cpuidle_device *dev,
> >>   					 struct cpuidle_driver *drv,
> >>   					 int index)
> >> @@ -238,6 +239,8 @@ static __cpuidle int tegra_cpuidle_enter(struct cpuidle_device *dev,
> >>   	if (dev->states_usage[index].disable)
> >>   		return -1;
> >>   
> >> +	console_irqwork_blocked = true;
> >> +
> >>   	if (index == TEGRA_C1) {
> >>   		if (do_rcu)
> >>   			ct_cpuidle_enter();
> >> @@ -256,6 +259,8 @@ static __cpuidle int tegra_cpuidle_enter(struct cpuidle_device *dev,
> >>   		index = ret;
> >>   	}
> >>   
> >> +	console_irqwork_blocked = false;
> >> +
> >>   	return index;
> >>   }
> >> ===== END CPUIDLE HACK =====
> >
> > Yes that does boot.
> 
> 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?
> 
> 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.
> 
> 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?

I wonder how other architectures hanle this situation. I wonder
if they just ignore the pending IRQs.

Best Regards,
Petr