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

[John Ogness]

On 2026-08-25, Jon Hunter <jonathanh@xxxxxxxxxx> 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?

John