Hi Guillaume,
On Wed, Dec 14, 2022 at 3:16 PM Guillaume Tucker
<guillaume.tuc...@collabora.com> wrote:
> On 14/12/2022 15:03, Geert Uytterhoeven wrote:
> > On Wed, Dec 14, 2022 at 1:54 PM Guillaume Tucker
> > <guillaume.tuc...@collabora.com> wrote:
> >> On 14/12/2022 11:06, Geert Uytterhoeven wrote:
> >>> On Tue, Dec 13, 2022 at 5:58 PM Mark Brown <broo...@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.
> As you can see, Geert is not listed there.
Sorry, it was indeed not sent explicitly to me, but I was mentioned,
so I noticed.
> >> 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?
>
> Sorry then I guess it wasn't rebased but if mainline was merged
> into the branch then it inherited the regressions from mainline
> at that point.
Yep.
> >> 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).
>
> No, the issues aren't reported more than once. And again, the
> tree used to do the bisection is not relevant as what matters is
> the commit that it found.
>
> >> 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".
>
> Regressions are basically a delta between results in a given
> revision and the previous one on the same branch (new failures).
> What I call "2nd order" regressions are a delta of these
> regressions compared to another reference branch. For example,
> regressions that are in a particular tree and aren't also in
> mainline such as the one at hand which isn't specific to renesas.
This regression must also be present in mainline (in v6.1).
> >> 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.
>
> I think it won't be to implement this as soon as we start
> tracking regressions specific to each tree since we'll have valid
> good/bad revisions that are relevant to the tree in the first
> place (if I understand correctly what you mean here).
My point is that regressions should be reported against the tree where
they truly originated, not against a random tree that merged upstream.
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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
