Thorsten Leemhuis <regressions@xxxxxxxxxxxxx> writes: > On 23.05.23 21:44, Sergey Organov wrote: >> "Linux regression tracking (Thorsten Leemhuis)" >> <regressions@xxxxxxxxxxxxx> 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
