Re: [PATCH tty 1/1] serial: 8250: Change console_msr_work to IRQ_WORK_LAZY

[Sebastian Andrzej Siewior <bigeasy@linutronix.de>]

On 2026-08-28 18:06:50 [+0100], Jon Hunter wrote:
> 
> On 28/08/2026 17:06, Sebastian Andrzej Siewior wrote:
> > On 2026-08-28 18:04:08 [+0206], John Ogness wrote:
> > > For some platforms it is a problem to queue irq_work when entering
> > > cpuidle states. Since irq_work is used for deferred MSR handling,
> > > any atomic console printing when entering cpuidle states can lead
> > > to the affected hardware hanging. Tegra20 and Tegra30 are examples
> > > of such platforms. Avoiding raising the irq_work IRQ has shown to
> > > circumvent the problem.
> > 
> > I would argue that this is done for the benefit of less interrupts since
> > there no need to handle console_msr_work immediately. With the side
> > effect that it might fix a bug that was not yet reported on Tegra[23]0.
> > 
> > Ideally the Tegra folks should figure out what exactly is broken instead
> > of adding duct tape everywhere else.
> 
> Yes that would be ideal. Unfortunately these are old devices now and very
> much in maintenance mode so getting to the bottom of this now is unlikely.

So this is maintenance mode.

> You may say then why don't we completely deprecate these, but then you
> could argue the other way and say they have been working fine up until
> now.

So a couple of years ago this platform stalled printk development due
its irq_work usage. Now again. Imagine we would have a ext4 feature
which freezes just this platform on boot. What would happen here?

The current workaround is to use LAZY which in general defers the IRQ
work to the next tick and it works for you. If you enable NOHZ and the
CPU goes tickless even a scheduled LAZY irq-work will raise the irq-work
interrupt to ensure the CPU does not go idle and we do have a wake up.

This might bring the problem back at some point.

> Jon

Sebastian