[CCing the stable list as well as Greg and Sasha so they can correct me if I write something stupid]
On 06.04.23 10:27, Ricardo Cañuelo wrote:
On 5/4/23 19:14, Thorsten Leemhuis wrote:
Wait, what? A patch (5225e1b87432 ("ARM: dts: meson: Fix the UART compatible strings")) that was merged for v5.17-rc4 and is not in the list of patches that were in 4.14.312-rc1 (https://lore.kernel.org/all/20230403140351.636471867@linuxfoundation.org/ ) is meant to suddenly cause this? How is this possible? Am I totally on the wrong track here and misunderstanding something, or is this a bisection that went horribly sideways?
I didn't say this was introduced in 4.14.312-rc1, this has been failing for a long time and it was merged for 4.14.267: https://lwn.net/Articles/884977/
Sorry I wasn't clear before.
Ahh, no worries and thx for this. But well, in that case let me get back to something from your report:
KernelCI detected that this patch introduced a regression in stable-rc/linux-4.14.y on a meson8b-odroidc1. After this patch was applied the tests running on this platform don't show any serial output.
This doesn't happen in other stable branches nor in mainline, but 4.14 hasn't still reached EOL and it'd be good to find a fix.
Well, the stable maintainers may correct me if I'm wrong, but as far as I know in that case it's the duty of the stable team (which was not even CCed on the report afaics) to look into this for two reasons:
* the regression does not happened in mainline (and maybe never has)
* mainline developers never signed up for maintaining their work in longterm kernels; quite a few nevertheless help in situation like this, at least for recent series and if they asked for a backport through a "CC: <stable@" tag – but the latter doesn't seem to be the case here (not totally sure, but it looks like AUTOSEL picked this up) and it's a quite old series.
#regzbot introduced: 5225e1b87432dcf0d0fc3440824b91d04c1d6cc1
Thx for getting regzbot involved, but due to your usage it now considers this a mainline regression, as 5225e1b87432 is a mainline commit. As this only happens in a particular stable tree, it should use a commit id from there instead:
#regzbot introduced: 23dfa42a0a2a91d640ef3fce585194b970d8680c
(above line will make regzbot adjust this)
Ciao, Thorsten
On Thu, Apr 06, 2023 at 11:06:50AM +0200, Thorsten Leemhuis wrote:
[CCing the stable list as well as Greg and Sasha so they can correct me if I write something stupid]
On 06.04.23 10:27, Ricardo Cañuelo wrote:
On 5/4/23 19:14, Thorsten Leemhuis wrote:
Wait, what? A patch (5225e1b87432 ("ARM: dts: meson: Fix the UART compatible strings")) that was merged for v5.17-rc4 and is not in the list of patches that were in 4.14.312-rc1 (https://lore.kernel.org/all/20230403140351.636471867@linuxfoundation.org/ ) is meant to suddenly cause this? How is this possible? Am I totally on the wrong track here and misunderstanding something, or is this a bisection that went horribly sideways?
I didn't say this was introduced in 4.14.312-rc1, this has been failing for a long time and it was merged for 4.14.267: https://lwn.net/Articles/884977/
Sorry I wasn't clear before.
Ahh, no worries and thx for this. But well, in that case let me get back to something from your report:
KernelCI detected that this patch introduced a regression in stable-rc/linux-4.14.y on a meson8b-odroidc1. After this patch was applied the tests running on this platform don't show any serial output.
This doesn't happen in other stable branches nor in mainline, but 4.14 hasn't still reached EOL and it'd be good to find a fix.
Well, the stable maintainers may correct me if I'm wrong, but as far as I know in that case it's the duty of the stable team (which was not even CCed on the report afaics) to look into this for two reasons:
the regression does not happened in mainline (and maybe never has)
mainline developers never signed up for maintaining their work in
longterm kernels; quite a few nevertheless help in situation like this, at least for recent series and if they asked for a backport through a "CC: <stable@" tag – but the latter doesn't seem to be the case here (not totally sure, but it looks like AUTOSEL picked this up) and it's a quite old series.
That is all true.
So can the original report be sent to stable@vger.kernel.org and we can take it from there?
thanks,
greg k-h
Thanks Thorsten and Greg,
I sent the original report to stable@vger.kernel.org. Sorry for the confusion, I'm still learning about how report regressions properly using regzbot, specially for stable branches. Thorsten's guidelines are being very helpful here.
Cheers, Ricardo
On 10.04.23 08:09, Ricardo Cañuelo wrote:
I sent the original report to stable@vger.kernel.org.
thx! let me tell regzbot about it:
#regzbot monitor: https://lore.kernel.org/all/1fcff522-337a-c334-42a7-bc9b4f0daec4@collabora.c... #regzbot ignore-activity
Sorry for the confusion, I'm still learning about how report regressions properly using regzbot, specially for stable branches. Thorsten's guidelines are being very helpful here.
Great to hear! But FWIW, I really should try to find some time to fine tune reporting-issues.rst, reporting-regressions.rst, and handling-regressions.rst some more, as there are quite a few things that afaics could or need to be improved. Especially the aspect "stable/longterm is handled by different set of people (but regular developers might help)" is something that needs to become clearer afaics.
But there is still this "there are only 24 hours in a day, but so many things to do" problem...
Ciao, Thorsten
linux-stable-mirror@lists.linaro.org
-
Greg KH -
Linux regression tracking (Thorsten Leemhuis) -
Ricardo Cañuelo -
Thorsten Leemhuis