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

[Jon Hunter <jonathanh@nvidia.com>]

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