Hi Guillaume,
On Wed, Dec 14, 2022 at 1:54 PM Guillaume Tucker
<guillaume.tucker@xxxxxxxxxxxxx> wrote:
> On 14/12/2022 11:06, Geert Uytterhoeven wrote:
> > On Tue, Dec 13, 2022 at 5:58 PM Mark Brown <broonie@xxxxxxxxxx> wrote:
> >> On Tue, Dec 13, 2022 at 05:56:30AM -0800, KernelCI bot wrote:
> >> The KernelCI bisection bot found regressions in at least two KMS tests
> >> in the Renesas tree on rk3399-gru-kevin just after the Renesas tree
> >> merged up mainline:
> >>
> >> igt-kms-rockchip.kms_vblank.pipe-A-wait-forked
> >> igt-kms-rockchip.kms_vblank.pipe-A-query-busy
> >>
> >> which it bisected to ca871659ec16 ("drm/bridge: analogix_dp: Support
> >> PSR-exit to disable transition"). I'm not *100%* sure I trust the
> >> bisection but it sure is suspicous that two separate bisects for related
> >> issues landed on the same commit.
> >
> > ... which is an old commit, added in v5.19-rc2, and which did not
> > enter through the renesas tree at all?
>
> Do you mean this report shouldn't have been sent to you?
Exactly.
> FYI The renesas tree got rebased and inherited a regression which
> got bisected.
Renesas/master is (usually) never rebased.
So when did this rebase happen, and why is it relevant?
> The same thing probably happened to other trees.
Indeed, I expect any tree that merged v5.19-rc2 or later to contain
this regression. That doesn't mean it's a good idea to tell all
consumers of v5.19-rc2 and later they got a regression (and make it
sound like the problem was introduced in their trees).
> Yes it would be good to have 2nd order regressions based on a
> reference branch (e.g. mainline in this case) in KernelCI but
Sorry, I don't know what is a "2nd order regression".
> that's for next year. Regardless, it found a commit and the
> bisection looks legit.
Good. So please report it to the relevant parties.
While bisecting, as soon as you happen to arrive at a commit
that is already upstream...
> git bisect start
> # good: [997b2d66ff4e40ef6a5acf76452e8c21104416f7] Merge branch
'renesas-next' into renesas-devel
> git bisect good 997b2d66ff4e40ef6a5acf76452e8c21104416f7
> # bad: [710ce3a8a6fbfcd81d8ad361dc9d43c6a785f25e] Merge tag
'v6.1' into renesas-devel
> git bisect bad 710ce3a8a6fbfcd81d8ad361dc9d43c6a785f25e
> # bad: [044610f8e4155ec0374f7c8307b725b7d01d750c] Merge tag
'ata-6.0-rc2' of
git://git.kernel.org/pub/scm/linux/kernel/git/dlemoal/libata
> git bisect bad 044610f8e4155ec0374f7c8307b725b7d01d750c
(which happens here ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^)
... there is no point in "blaming" any of the bisection points before.
The git command to check this is (assumed "linus" is a remote pointing
to Linus' tree):
git branch -a --contains 044610f8e4155ec0374f7c8307b725b7d01d750c
linus/master
You can use similar commands to find the maintainer's tree for commits
that are in linux-next and in a for-next branch, but not yet upstream.
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
