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

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

[Guillaume Tucker]

Hi Mark,

Maybe you could retrieve the original thread and rely to it with
the report?  That's the ideal way of following up on a patch I
think.  You can get the mbox file this way:

./kci_bisect get_mbox \
  --commit ca871659ec1606d33b1e76de8d4cf924cf627e34 \
  --kdir ~/src/linux


On 14/12/2022 11:06, Geert Uytterhoeven wrote:
> Hi Mark,
> 
> Thanks for your report!
> 
> On Tue, Dec 13, 2022 at 5:58 PM Mark Brown <broonie@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?

FYI The renesas tree got rebased and inherited a regression which
got bisected.  The same thing probably happened to other 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
that's for next year.  Regardless, it found a commit and the
bisection looks legit.

>> Below is the full report for the bisect for the first test, the bisect
>> for the latter looks identical.  It's got links to full logs for the
>> test run and a Reported-by for the bot - I do see some backtraces from
>> userspace in the output, the first is:
>>
>> | IGT-Version: 1.26-gf8a4a0b (aarch64) (Linux: 6.1.0 aarch64)
>> | <14>[   35.444448] [IGT] drm_read: starting subtest short-buffer-wakeup
>> | Starting subtest: short-buffer-wakeup
>> |
>> | (| drm_read:350) CRITICAL: Test assertion failure function generate_event, file ../tests/drm_read.c:65:
>> | (drm_read:350) CRITICAL: <14>[   36.155642] [IGT] drm_read: exiting, ret=98
>> | Failed assertion: kmstest_get_vblank(fd, pipe, DRM_VBLANK_EVENT)
>> |
>> | (drm_read:350) CRITICAL: Last errno: 22, Invalid argument
>> | Stack trace:
>> |
>> |   #0 ../lib/igt_core.c:1933 __igt_fail_assert()
>> |   #1 [<unknown>+0xd5362770]
>> |   #2 [<unknown>+0xd536193c]
>> |   #3 [__libc_start_main+0xe8]
>> |   #4 [<unknown>+0xd5361974]
>> |   #5 [<unknown<6>[   36.162851] Console: switching to colour frame buffer device 300x100>+0xd5361974]
>> | Subtest short-buffer-wakeup failed.
>>
>> Unfortunately we don't have current results from mainline or -next.

Thanks,
Guillaume

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 982 bytes --]

On Wed, Dec 14, 2022 at 01:55:03PM +0100, Guillaume Tucker wrote:

> Maybe you could retrieve the original thread and rely to it with
> the report?  That's the ideal way of following up on a patch I
> think.  You can get the mbox file this way:

> ./kci_bisect get_mbox \
>   --commit ca871659ec1606d33b1e76de8d4cf924cf627e34 \
>   --kdir ~/src/linux

As a developer I tend to find this unhelpful, it makes it much more
likely that the mail will get missed.  As a reporter it means there's
more information to copy into the report.

> > ... 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?

I do notice that the Renesas tree tends to get a *lot* of the bisection
reports generated for some reason (vastly more than any other tree
including mainline or -next), however this wasn't sent based on the tree
at all - I just looked at the people involved with the commit.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: 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@collabora.com> wrote:
> On 14/12/2022 11:06, Geert Uytterhoeven wrote:
> > On Tue, Dec 13, 2022 at 5:58 PM Mark Brown <broonie@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@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

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

[Guillaume Tucker]

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

OK.

Mark, how did you get the list of recipients?

There's a command for this btw, which was used when the reports
were automatically sent to the recipients before we reverted to
manual filtering to reduce the noise:

$ ./kci_bisect get_recipients --kdir ~/src/linux --commit ca871659ec1606d33b1e76de8d4cf924cf627e34
To:
  Douglas Anderson <dianders@chromium.org>
  Brian Norris <briannorris@chromium.org>
  Sean Paul <seanpaul@chromium.org>
Cc:
  Miaoqian Lin <linmq006@gmail.com>
  Andrzej Hajda <a.hajda@samsung.com>
  Jonas Karlman <jonas@kwiboo.se>
  Daniel Vetter <daniel@ffwll.ch>
  Robert Foss <robert.foss@linaro.org>
  Jernej Skrabec <jernej.skrabec@gmail.com>
  Heiko Stuebner <heiko@sntech.de>
  Sasha Levin <sashal@kernel.org>
  linux-kernel@vger.kernel.org
  dri-devel@lists.freedesktop.org
  Laurent Pinchart <Laurent.pinchart@ideasonboard.com>
  Neil Armstrong <narmstrong@baylibre.com>
  Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  David Airlie <airlied@linux.ie>

As you can see, Geert is not listed there.

>> 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.

>>  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.

>> 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).

Thanks,
Guillaume

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

[Guillaume Tucker]

On 14/12/2022 14:50, Mark Brown wrote:
> On Wed, Dec 14, 2022 at 01:55:03PM +0100, Guillaume Tucker wrote:
> 
>> Maybe you could retrieve the original thread and rely to it with
>> the report?  That's the ideal way of following up on a patch I
>> think.  You can get the mbox file this way:
> 
>> ./kci_bisect get_mbox \
>>   --commit ca871659ec1606d33b1e76de8d4cf924cf627e34 \
>>   --kdir ~/src/linux
> 
> As a developer I tend to find this unhelpful, it makes it much more
> likely that the mail will get missed.  As a reporter it means there's
> more information to copy into the report.


Well it's up to you or anyone reporting the bisection result.
Base on my personal experience, I always got very quick replies
when doing this.

I don't see your point about copying more information though, I
would just open the mbox in my mail client to reply and paste the
content of the bisection report.  With a bit more work this could
be fully automated but that should be part of the bisection
rework using the new API & pipeline so sometime later in 2023...

>>> ... 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?
> 
> I do notice that the Renesas tree tends to get a *lot* of the bisection
> reports generated for some reason (vastly more than any other tree
> including mainline or -next), however this wasn't sent based on the tree
> at all - I just looked at the people involved with the commit.

In the past month, there were 15 bisection reports on renesas, 7
on linux-next and 28 on mainline for a total of 79 so 29 in other
trees.  So it's true renesas is getting quite a lot of them, it's
not entirely clear to me why that's the case but it's worth
investigating a bit.

See my other email about "kci_bisect get_recipients".

Thanks,
Guillaume

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 3281 bytes --]

On Wed, Dec 14, 2022 at 03:16:33PM +0100, Guillaume Tucker wrote:

> Mark, how did you get the list of recipients?

> There's a command for this btw, which was used when the reports
> were automatically sent to the recipients before we reverted to
> manual filtering to reduce the noise:

My standard thing is to look at who touched the commit, possibly also
adding seemingly relevant maintainers depending on how good the list
from the commit was (IIRC in this case the commit went entirely through
ChromeOS people so I added relevant DRM submaintainers which turned out
to be a surprisingly large number of people), and relevant lists.

> As you can see, Geert is not listed there.

I didn't send the report to Geert as far as I can see, I imagine he saw
it as a result of it going to one of the lists and noticed the mention
of Renesas as the tree, possibly he's got some filter set up to find
things that mention it.  The recipient list I have is:

| To: kernelci-results@groups.io, bot@kernelci.org, Brian Norris
|         <briannorris@chromium.org>, Sean Paul <seanpaul@chromium.org>, Douglas
|         Anderson <dianders@chromium.org>
| Cc: gtucker@collabora.com, dri-devel@lists.freedesktop.org,
|         linux-arm-kernel@lists.infradead.org, Andrzej Hajda
|         <andrzej.hajda@intel.com>, Neil Armstrong <neil.armstrong@linaro.org>,
|         Robert Foss <robert.foss@linaro.org>, Laurent Pinchart
|         <Laurent.pinchart@ideasonboard.com>, Jonas Karlman <jonas@kwiboo.se>,
|         Jernej Skrabec <jernej.skrabec@gmail.com>

which doesn't mention him at all.

> >> 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.

Like I said in the other mail there is something going on which means
that a *very* lerge proportion of our bisection results are found in the
Renesas tree.

> >> that's for next year.  Regardless, it found a commit and the
> >> bisection looks legit.

> > Good. So please report it to the relevant parties.

That's what I did...

> > While bisecting, as soon as you happen to arrive at a commit
> > that is already upstream...

> > '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.

I'm not sure I understand the logic here?  The goal with a bisection is
to identify which commit caused an issue to aid in resolving whatever
the problem is.  It doesn't really matter if this happens before or
after the commit lands in Linus' tree.  I do agree that the tree
mentioned becomes a bit misleading though.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1751 bytes --]

On Wed, Dec 14, 2022 at 03:27:56PM +0100, Guillaume Tucker wrote:
> On 14/12/2022 14:50, Mark Brown wrote:

> > As a developer I tend to find this unhelpful, it makes it much more
> > likely that the mail will get missed.  As a reporter it means there's
> > more information to copy into the report.

> Well it's up to you or anyone reporting the bisection result.
> Base on my personal experience, I always got very quick replies
> when doing this.

For me on the recipient side it's more a question of if you get any at
all.

> I don't see your point about copying more information though, I
> would just open the mbox in my mail client to reply and paste the
> content of the bisection report.  With a bit more work this could
> be fully automated but that should be part of the bisection
> rework using the new API & pipeline so sometime later in 2023...

If I'm manually pasing stuff I either have to quote it by hand or feel
like I need to edit the automatically generated bits.

> > I do notice that the Renesas tree tends to get a *lot* of the bisection
> > reports generated for some reason (vastly more than any other tree
> > including mainline or -next), however this wasn't sent based on the tree
> > at all - I just looked at the people involved with the commit.

> In the past month, there were 15 bisection reports on renesas, 7
> on linux-next and 28 on mainline for a total of 79 so 29 in other
> trees.  So it's true renesas is getting quite a lot of them, it's
> not entirely clear to me why that's the case but it's worth
> investigating a bit.

Yeah, that's vastly more than I'd expect and the overwhelming majority
of them are quite clearly not specific to the Renesas tree (things like
bootrr failures for non-Renesas boards).

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Geert Uytterhoeven]

Hi Mark,

On Wed, Dec 14, 2022 at 3:39 PM Mark Brown <broonie@kernel.org> wrote:
> On Wed, Dec 14, 2022 at 03:16:33PM +0100, Guillaume Tucker wrote:
> > Mark, how did you get the list of recipients?
>
> > There's a command for this btw, which was used when the reports
> > were automatically sent to the recipients before we reverted to
> > manual filtering to reduce the noise:
>
> My standard thing is to look at who touched the commit, possibly also
> adding seemingly relevant maintainers depending on how good the list
> from the commit was (IIRC in this case the commit went entirely through
> ChromeOS people so I added relevant DRM submaintainers which turned out
> to be a surprisingly large number of people), and relevant lists.
>
> > As you can see, Geert is not listed there.
>
> I didn't send the report to Geert as far as I can see, I imagine he saw
> it as a result of it going to one of the lists and noticed the mention
> of Renesas as the tree, possibly he's got some filter set up to find
> things that mention it.  The recipient list I have is:
>
> | To: kernelci-results@groups.io, bot@kernelci.org, Brian Norris
> |         <briannorris@chromium.org>, Sean Paul <seanpaul@chromium.org>, Douglas
> |         Anderson <dianders@chromium.org>
> | Cc: gtucker@collabora.com, dri-devel@lists.freedesktop.org,
> |         linux-arm-kernel@lists.infradead.org, Andrzej Hajda
> |         <andrzej.hajda@intel.com>, Neil Armstrong <neil.armstrong@linaro.org>,
> |         Robert Foss <robert.foss@linaro.org>, Laurent Pinchart
> |         <Laurent.pinchart@ideasonboard.com>, Jonas Karlman <jonas@kwiboo.se>,
> |         Jernej Skrabec <jernej.skrabec@gmail.com>
>
> which doesn't mention him at all.

Right. I noticed the email because my name was in the body (it's part
of the git repo name).
The "Re: renesas/master bisection" in the subject immediately triggered
my interest.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@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

Re: 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 3:16 PM Guillaume Tucker
<guillaume.tucker@collabora.com> wrote:
> On 14/12/2022 15:03, Geert Uytterhoeven wrote:
> > On Wed, Dec 14, 2022 at 1:54 PM Guillaume Tucker
> > <guillaume.tucker@collabora.com> wrote:
> >> On 14/12/2022 11:06, Geert Uytterhoeven wrote:
> >>> On Tue, Dec 13, 2022 at 5:58 PM Mark Brown <broonie@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 -- geert@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