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

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 at chromium.org>
  Brian Norris <briannorris at chromium.org>
  Sean Paul <seanpaul at chromium.org>
Cc:
  Miaoqian Lin <linmq006 at gmail.com>
  Andrzej Hajda <a.hajda at samsung.com>
  Jonas Karlman <jonas at kwiboo.se>
  Daniel Vetter <daniel at ffwll.ch>
  Robert Foss <robert.foss at linaro.org>
  Jernej Skrabec <jernej.skrabec at gmail.com>
  Heiko Stuebner <heiko at sntech.de>
  Sasha Levin <sashal at kernel.org>
  linux-kernel at vger.kernel.org
  dri-devel at lists.freedesktop.org
  Laurent Pinchart <Laurent.pinchart at ideasonboard.com>
  Neil Armstrong <narmstrong at baylibre.com>
  Greg Kroah-Hartman <gregkh at linuxfoundation.org>
  David Airlie <airlied at 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