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

[Jon Hunter]

On 31/08/2026 09:20, Sebastian Andrzej Siewior wrote:
> 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?

I simply reported a regression. I did not set out to stall any work.
If the work stalled because of this issue alone, why was this not
discussed back when this happened? I am sure we could have come to
a reasonable comprise.

Please note that these legacy boards have caught some other issues in
the past and so I do see some value in keeping them working. This one
is a bit of an odd ball because clearly this platform has some issues
related to CPU idle. Again we are happy to discuss that and come to a
reasonable comprise.
> 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.

That may be, and we will cross that bridge if and when we come to it.

Jon

--
nvpublic