Regression: serial: imx: overrun errors on debug UART

[Stefan Wahren]

Hi Lucas,

Am 20.06.23 um 18:40 schrieb Lucas Stach:
> Am Dienstag, dem 20.06.2023 um 18:30 +0200 schrieb Stefan Wahren:
>> Hi Greg,
>>
>> Am 20.06.23 um 16:59 schrieb Greg Kroah-Hartman:
>>> On Tue, Jun 20, 2023 at 04:47:10PM +0200, Linux regression tracking (Thorsten Leemhuis) wrote:
>>>> On 24.05.23 15:07, Stefan Wahren wrote:
>>>>>
>>>>> Am 23.05.23 um 21:44 schrieb Sergey Organov:
>>>>>> "Linux regression tracking (Thorsten Leemhuis)"
>>>>>> <regressions at leemhuis.info> writes:
>>>>>>
>>>>>> Solving this would need to identify the cause of interrupts being
>>>>>> disabled for prolonged times, and nobody volunteered to investigate this
>>>>>> further. One suspect, the Linux serial console, has been likely excluded
>>>>>> already though, as not actually being in use for printk() output.
>>>>>>
>>>>>
>>>>> I don't think that we can exclude the serial console as a whole, i never
>>>>> made such a observation. But at least we can exclude kernel logging on
>>>>> the debug UART.
>>>>
>>>> Stefan, just wondering: was this ever addressed upstream? I assume it's
>>>> not, just wanted to be sure.
>>>>
>>>> I'm a bit unsure what to do with this and consider asking Greg for
>>>> advice, as he applied the patch. On one hand it's *IMHO* clearly a
>>>> regression (but for the record,  some people involved in the discussion
>>>> claim it's not). OTOH the culprit was applied more than a year ago now,
>>>> so reverting it might cause more trouble than it's worth at this point,
>>>> as that could lead to regressions for other users.
>>>
>>> I'll be glad to revert this, but for some reason I thought that someone
>>> was working on a "real fix" here.  Stefan, is that not the case?
>>
>> i can only repeat the statements from 23.5.:
>>
>> Unfortunately my time budget to investigate this issue further is
>> exhausted, so i stopped working at this.
>>
>> In case someone can give clear instructions to investigate this further,
>> i will try to look at it in my spare time. But i cannot make any promises.
>>
> If the cause is simply interrupts not being serviced for a long period
> of time, the irqsoff tracer is usually a very good start to investigate
> the issue. It might point to a smoking gun already.

thanks the hint, i can try that.

AFAIR there was a kernel comment which pointed out that console IO (or 
at least parts) is excluded from the irqoff tracer?

> 
> Regards,
> Lucas
> 
>> I'm not aware that some else is working on this.
>>
>> Best regards
>>
>>>
>>> thanks,
>>>
>>> greg k-h
>>
>