Re: Regression: serial: imx: overrun errors on debug UART

From: Sergey Organov <sorganov@gmail.com>
To: Thorsten Leemhuis <regressions@leemhuis.info>
Cc: "Stefan Wahren" <stefan.wahren@i2se.com>,
	"Linux regressions mailing list" <regressions@lists.linux.dev>,
	"Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
	"Fabio Estevam" <festevam@gmail.com>,
	"Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>,
	"Stefan Wahren" <stefan.wahren@chargebyte.com>,
	linux-serial@vger.kernel.org,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Sascha Hauer" <s.hauer@pengutronix.de>,
	"NXP Linux Team" <linux-imx@nxp.com>,
	"Pengutronix Kernel Team" <kernel@pengutronix.de>,
	"Shawn Guo" <shawnguo@kernel.org>,
	"Jiri Slaby" <jirislaby@kernel.org>,
	"Tomasz Moń" <tomasz.mon@camlingroup.com>,
	"Linux ARM" <linux-arm-kernel@lists.infradead.org>
Subject: Re: Regression: serial: imx: overrun errors on debug UART
Date: Wed, 24 May 2023 16:45:10 +0300	[thread overview]
Message-ID: <87a5xtyhax.fsf@osv.gnss.ru> (raw)
In-Reply-To: <80207a43-6047-4493-da5d-8bd87ef74551@leemhuis.info> (Thorsten Leemhuis's message of "Wed, 24 May 2023 12:48:51 +0200")

Thorsten Leemhuis <regressions@leemhuis.info> writes:

> On 23.05.23 21:44, Sergey Organov wrote:
>> "Linux regression tracking (Thorsten Leemhuis)"
>> <regressions@leemhuis.info> writes:
>> 
>>> Hi, Thorsten here, the Linux kernel's regression tracker. Top-posting
>>> for once, to make this easily accessible to everyone.
>>>
>>> Stefan, was this regression ever solved? It doesn't look like it, but
>>> maybe I'm missing something.
>>>
>>> If it wasn't solved: what needs to be done to get this rolling again?
>> 
>> Not Stefan,
>
> Thx to both you and Stefan for the update.
>
>> but as far as I can tell, the problem is that on Stefan's
>> build the kernel has rather large periods of interrupts being disabled,
>> so any attempt to decrease IRQs frequency from UART by raising FIFO IRQ
>> threshold causes "regression" that manifests itself as missing
>> characters on receive. I'm not sure if it's tuning FIFO level that is in
>> fact a regression in this case.
>
> Not totally sure, but I guess Linus stance in this case would be along
> the lines of "commit 7a637784d517 made an existing issue worse; either
> the people involved in it fix it, or we revert that commit[1], as it's
> causing a regression". At least we *iirc* had situations he handled like
> that.

From Stefan's investigations it follows that the kernel has interrupts
disabled for about 2.5 milliseconds! If that's an acceptable value for
Linux kernel, then the commit in question is a regression. If not, and
in my opinion that's too high a number, then it's not a regression at
all, but rather a manifestation of a problem (bug?) elsewhere.

>
> [1] of course unless a revert would cause regressions for others --
> which i guess might be the case here, as that was added in 5.18 already.
> So let's not bring Linus in.
>
>> Solving this would need to identify the cause of interrupts being
>> disabled for prolonged times, and nobody volunteered to investigate this
>> further. 
>
> Well, Stefan kind of did to do so in his spare time, but asked for
> "clear instructions to investigate this further". Could you maybe
> provide those? If not: who could?

There should be somebody who is familiar with methods to isolate the
victim of abnormal interrupts latencies, but I'm not the one, sorry.

Thanks,
-- Sergey Organov