[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <de92e3bd-70e8-fcba-3c88-c04170704e7b@collabora.com>
Date: Tue, 28 May 2019 09:36:03 +0100
From: Guillaume Tucker <guillaume.tucker@...labora.com>
To: Geert Uytterhoeven <geert@...ux-m68k.org>
Cc: Elaine Zhang <zhangqing@...k-chips.com>,
Eduardo Valentin <edubezval@...il.com>,
Daniel Lezcano <daniel.lezcano@...aro.org>,
Heiko Stuebner <heiko@...ech.de>,
Linus Walleij <linus.walleij@...aro.org>,
Tomeu Vizoso <tomeu.vizoso@...labora.com>,
Linux PM list <linux-pm@...r.kernel.org>,
Kevin Hilman <khilman@...libre.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
"open list:ARM/Rockchip SoC..." <linux-rockchip@...ts.infradead.org>,
Mark Brown <broonie@...nel.org>,
Matt Hart <matthew.hart@...aro.org>, mgalka@...labora.com,
Enric Balletbo i Serra <enric.balletbo@...labora.com>,
Zhang Rui <rui.zhang@...el.com>,
Linux ARM <linux-arm-kernel@...ts.infradead.org>
Subject: Re: linusw/for-next boot bisection: v5.2-rc1-8-g73a790c68d7e on
rk3288-veyron-jaq
Hi Geert,
On 28/05/2019 08:45, Geert Uytterhoeven wrote:
> Hi Guillaume,
>
> On Tue, May 28, 2019 at 9:13 AM Guillaume Tucker
> <guillaume.tucker@...labora.com> wrote:
>> On 28/05/2019 00:38, kernelci.org bot wrote:
>>> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
>>> * This automated bisection report was sent to you on the basis *
>>> * that you may be involved with the breaking commit it has *
>>> * found. No manual investigation has been done to verify it, *
>>> * and the root cause of the problem may be somewhere else. *
>>> * Hope this helps! *
>>> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
>>>
>>> linusw/for-next boot bisection: v5.2-rc1-8-g73a790c68d7e on rk3288-veyron-jaq
>>>
>>> Summary:
>>> Start: 73a790c68d7e Merge branch 'devel' into for-next
>>> Details: https://kernelci.org/boot/id/5cebf03d59b514dd627a3629
>>> Plain log: https://storage.kernelci.org//linusw/for-next/v5.2-rc1-8-g73a790c68d7e/arm/multi_v7_defconfig/gcc-8/lab-collabora/boot-rk3288-veyron-jaq.txt
>>> HTML log: https://storage.kernelci.org//linusw/for-next/v5.2-rc1-8-g73a790c68d7e/arm/multi_v7_defconfig/gcc-8/lab-collabora/boot-rk3288-veyron-jaq.html
>>> Result: 28694e009e51 thermal: rockchip: fix up the tsadc pinctrl setting error
>>>
>>> Checks:
>>> revert: PASS
>>> verify: PASS
>>>
>>> Parameters:
>>> Tree: linusw
>>> URL: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git/
>>> Branch: for-next
>>> Target: rk3288-veyron-jaq
>>> CPU arch: arm
>>> Lab: lab-collabora
>>> Compiler: gcc-8
>>> Config: multi_v7_defconfig
>>> Test suite: boot
>>>
>>> Breaking commit found:
>>>
>>> -------------------------------------------------------------------------------
>>> commit 28694e009e512451ead5519dd801f9869acb1f60
>>> Author: Elaine Zhang <zhangqing@...k-chips.com>
>>> Date: Tue Apr 30 18:09:44 2019 +0800
>>>
>>> thermal: rockchip: fix up the tsadc pinctrl setting error
>>
>> This commit has now been reverted in mainline. Would it be OK
>> for you to rebase your for-next branch on v5.2-rc2 or cherry-pick
>> the revert to avoid recurring bisections?
>>
>> Ideally this should have been fixed or reverted in mainline
>> before v5.2-rc1 was released, or even earlier when this was first
>> found in -next on 13th May. Unfortunately it was overlooked and
>> then spread to other branches like yours.
>
> I'm afraid it's gonna spread to even more for-next branches, as most
> subsystem maintainers base their for-next branch on the previous rc1
> release. Typically maintainers do not rebase their for-next branches,
> and do not cherry-pick fixes, unless they are critical for their
> subsystem. So you can expect this to show up in e.g. the m68k for-next
> branch soon...
That is what I feared, thanks for confirming.
> Can't you mark this as a known issue, to prevent spending cycles on the
> same bisection, and sending out more bisection reports for the same
> issue?
Not really, so I've disabled bisections in the linux-gpio tree
and a few other maintainers' trees for now. I'll see if we can
come up with a more systematic way of suppressing bisections in
similar cases (i.e. the issue has been fixed in mainline later
than the base commit for the branch being tested).
Thanks,
Guillaume
Powered by blists - more mailing lists