renesas/master bisection: igt-kms-rockchip.kms_vblank.pipe-A-wait-forked on rk3399-gru-kevin

[Geert Uytterhoeven]

Hi Guillaume,

On Wed, Dec 14, 2022 at 1:54 PM Guillaume Tucker
<guillaume.tucker at collabora.com> wrote:
> On 14/12/2022 11:06, Geert Uytterhoeven wrote:
> > On Tue, Dec 13, 2022 at 5:58 PM Mark Brown <broonie at kernel.org> 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 at linux-m68k.org

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