Regression: serial: imx: overrun errors on debug UART

Lucas Stach l.stach at pengutronix.de
Tue Jun 20 09:40:21 PDT 2023


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.

Regards,
Lucas

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




More information about the linux-arm-kernel mailing list