All of lore.kernel.org
 help / color / mirror / Atom feed
From: Guillaume Tucker <guillaume.tucker@collabora.com>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: kernelci-results@groups.io, Johan Jonker <jbx6244@gmail.com>,
	Heiko Stuebner <heiko@sntech.de>,
	Maciej Matuszczyk <maccraft123mc@gmail.com>,
	Marc Zyngier <maz@kernel.org>,
	Jacob Chen <jacob2.chen@rock-chips.com>,
	Sandy Huang <hjc@rock-chips.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Chen-Yu Tsai <wens@csie.org>, Cameron Nemo <cnemo@tutanota.com>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
	<devicetree@vger.kernel.org>,
	Elaine Zhang <zhangqing@rock-chips.com>,
	Helen Koike <helen.koike@collabora.com>,
	Robin Murphy <robin.murphy@arm.com>,
	Shunqian Zheng <zhengsq@rock-chips.com>,
	Ezequiel Garcia <ezequiel@collabora.com>,
	Rob Herring <robh+dt@kernel.org>,
	Yifeng Zhao <yifeng.zhao@rock-chips.com>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	"open list:ARM/Rockchip SoC..."
	<linux-rockchip@lists.infradead.org>,
	Collabora Kernel ML <kernel@collabora.com>
Subject: Re: renesas/master bisection: baseline-nfs.bootrr.rockchip-usb2phy0-probed on rk3399-gru-kevin
Date: Wed, 28 Jul 2021 09:48:02 +0100	[thread overview]
Message-ID: <2fc2b898-434c-3288-2052-70b1e1427b39@collabora.com> (raw)
In-Reply-To: <CAMuHMdUi_=xnvYFgiWXxSyrfoMn0JJCcH+TXFUh+1JUf=4u87A@mail.gmail.com>

On 28/07/2021 09:17, Geert Uytterhoeven wrote:
> Hi Guillaume et al,
> 
> On Wed, Jul 28, 2021 at 8:05 AM Guillaume Tucker
> <guillaume.tucker@collabora.com> wrote:
>> Please see the bisection report below about usb2phy failing to
>> probe on rk3399-gru-kevin.
>>
>> Reports aren't automatically sent to the public while we're
>> trialing new bisection features on kernelci.org but this one
>> looks valid.
> 
> Thanks for your report!
> 
>> The bisection was run in the Renesas tree but the same regression
>> is present in mainline for both usb2phy0 and usb2phy1 devices:
> 
> Exactly, the faulty commit is part of v5.14-rc1.
> 
>>> Breaking commit found:
>>>
>>> -------------------------------------------------------------------------------
>>> commit 8c3d64251ac5c5a3d10364f6b07d3603ac1e7b4a
>>> Author: Johan Jonker <jbx6244@gmail.com>
>>> Date:   Tue Jun 1 18:47:59 2021 +0200
>>>
>>>     arm64: dts: rockchip: rename nodename for phy-rockchip-inno-usb2
> 
> P.S. KernelCI is sending lots of reports to linux-reneas-soc[1] for
>      (a) issues on non-Renesas platforms[2], and

One thing to distinguish here is that changes in a tree like the
Renesas one might actually break other platforms, even if it
seems unlikely.  But the improvement explained below addresses
this issue.

>      (b) issues not originating in the renesas-devel tree, like this one.

That is just because I found the bisection report from the
Renesas tree before getting one from mainline.  As we're manually
triaging reports, I mentioned it in my email.  And you're right,
we would need to take this into account before having all the
bisection reports sent automatically.

> Suggestions for improvement:
>   1. If a regression is detected in an upstream tree, there is no
>      need to report it for downstream trees, unless it affects
>      the downstream tree, or originated there.

That's right, we're working on an improvement to be able to
detect "2nd order" regressions, that is to say new failures in a
branch relatively to new failures in an upstream branch.  That
would be typically mainline or stable, but sometimes a subsystem
specific one.

>   2. If a regression is detected for a platform, there is no need
>      to report it for different platform trees, unless it originated
>      there.
> 
> BTW, I do look at the reports for Renesas platforms, but usually I
> don't see what's wrong, and the same platform works fine locally.

Until this has been improved, maybe we can just stop sending
email reports to linux-reneas-soc if they're mostly noise.  The
bisections will still run and reports like this one are sent to
the people and lists who are related to the changes in the patch
rather than the git tree so it's always relevant to them.

> Note that yesterday and today I get "Error while loading data from the
> server (error code: 500). Please contact the website administrator".

Yes that's because the Mongo DB service keeps crashing.  It's a
sysadmin issue that should hopefully get resolved soon, sorry for
the inconvenience.


Thanks for your feedback.

Best wishes,
Guillaume

> [1] https://lore.kernel.org/linux-renesas-soc/?q=kernelci.org
> [2] https://lore.kernel.org/linux-renesas-soc/60ff86ff.1c69fb81.dfe6f.6a7c@mx.google.com/


WARNING: multiple messages have this Message-ID (diff)
From: Guillaume Tucker <guillaume.tucker@collabora.com>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: kernelci-results@groups.io, Johan Jonker <jbx6244@gmail.com>,
	Heiko Stuebner <heiko@sntech.de>,
	Maciej Matuszczyk <maccraft123mc@gmail.com>,
	Marc Zyngier <maz@kernel.org>,
	Jacob Chen <jacob2.chen@rock-chips.com>,
	Sandy Huang <hjc@rock-chips.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Chen-Yu Tsai <wens@csie.org>, Cameron Nemo <cnemo@tutanota.com>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
	<devicetree@vger.kernel.org>,
	Elaine Zhang <zhangqing@rock-chips.com>,
	Helen Koike <helen.koike@collabora.com>,
	Robin Murphy <robin.murphy@arm.com>,
	Shunqian Zheng <zhengsq@rock-chips.com>,
	Ezequiel Garcia <ezequiel@collabora.com>,
	Rob Herring <robh+dt@kernel.org>,
	Yifeng Zhao <yifeng.zhao@rock-chips.com>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	"open list:ARM/Rockchip SoC..."
	<linux-rockchip@lists.infradead.org>,
	Collabora Kernel ML <kernel@collabora.com>
Subject: Re: renesas/master bisection: baseline-nfs.bootrr.rockchip-usb2phy0-probed on rk3399-gru-kevin
Date: Wed, 28 Jul 2021 09:48:02 +0100	[thread overview]
Message-ID: <2fc2b898-434c-3288-2052-70b1e1427b39@collabora.com> (raw)
In-Reply-To: <CAMuHMdUi_=xnvYFgiWXxSyrfoMn0JJCcH+TXFUh+1JUf=4u87A@mail.gmail.com>

On 28/07/2021 09:17, Geert Uytterhoeven wrote:
> Hi Guillaume et al,
> 
> On Wed, Jul 28, 2021 at 8:05 AM Guillaume Tucker
> <guillaume.tucker@collabora.com> wrote:
>> Please see the bisection report below about usb2phy failing to
>> probe on rk3399-gru-kevin.
>>
>> Reports aren't automatically sent to the public while we're
>> trialing new bisection features on kernelci.org but this one
>> looks valid.
> 
> Thanks for your report!
> 
>> The bisection was run in the Renesas tree but the same regression
>> is present in mainline for both usb2phy0 and usb2phy1 devices:
> 
> Exactly, the faulty commit is part of v5.14-rc1.
> 
>>> Breaking commit found:
>>>
>>> -------------------------------------------------------------------------------
>>> commit 8c3d64251ac5c5a3d10364f6b07d3603ac1e7b4a
>>> Author: Johan Jonker <jbx6244@gmail.com>
>>> Date:   Tue Jun 1 18:47:59 2021 +0200
>>>
>>>     arm64: dts: rockchip: rename nodename for phy-rockchip-inno-usb2
> 
> P.S. KernelCI is sending lots of reports to linux-reneas-soc[1] for
>      (a) issues on non-Renesas platforms[2], and

One thing to distinguish here is that changes in a tree like the
Renesas one might actually break other platforms, even if it
seems unlikely.  But the improvement explained below addresses
this issue.

>      (b) issues not originating in the renesas-devel tree, like this one.

That is just because I found the bisection report from the
Renesas tree before getting one from mainline.  As we're manually
triaging reports, I mentioned it in my email.  And you're right,
we would need to take this into account before having all the
bisection reports sent automatically.

> Suggestions for improvement:
>   1. If a regression is detected in an upstream tree, there is no
>      need to report it for downstream trees, unless it affects
>      the downstream tree, or originated there.

That's right, we're working on an improvement to be able to
detect "2nd order" regressions, that is to say new failures in a
branch relatively to new failures in an upstream branch.  That
would be typically mainline or stable, but sometimes a subsystem
specific one.

>   2. If a regression is detected for a platform, there is no need
>      to report it for different platform trees, unless it originated
>      there.
> 
> BTW, I do look at the reports for Renesas platforms, but usually I
> don't see what's wrong, and the same platform works fine locally.

Until this has been improved, maybe we can just stop sending
email reports to linux-reneas-soc if they're mostly noise.  The
bisections will still run and reports like this one are sent to
the people and lists who are related to the changes in the patch
rather than the git tree so it's always relevant to them.

> Note that yesterday and today I get "Error while loading data from the
> server (error code: 500). Please contact the website administrator".

Yes that's because the Mongo DB service keeps crashing.  It's a
sysadmin issue that should hopefully get resolved soon, sorry for
the inconvenience.


Thanks for your feedback.

Best wishes,
Guillaume

> [1] https://lore.kernel.org/linux-renesas-soc/?q=kernelci.org
> [2] https://lore.kernel.org/linux-renesas-soc/60ff86ff.1c69fb81.dfe6f.6a7c@mx.google.com/


_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

WARNING: multiple messages have this Message-ID (diff)
From: Guillaume Tucker <guillaume.tucker@collabora.com>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: kernelci-results@groups.io, Johan Jonker <jbx6244@gmail.com>,
	Heiko Stuebner <heiko@sntech.de>,
	Maciej Matuszczyk <maccraft123mc@gmail.com>,
	Marc Zyngier <maz@kernel.org>,
	Jacob Chen <jacob2.chen@rock-chips.com>,
	Sandy Huang <hjc@rock-chips.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Chen-Yu Tsai <wens@csie.org>, Cameron Nemo <cnemo@tutanota.com>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
	<devicetree@vger.kernel.org>,
	Elaine Zhang <zhangqing@rock-chips.com>,
	Helen Koike <helen.koike@collabora.com>,
	Robin Murphy <robin.murphy@arm.com>,
	Shunqian Zheng <zhengsq@rock-chips.com>,
	Ezequiel Garcia <ezequiel@collabora.com>,
	Rob Herring <robh+dt@kernel.org>,
	Yifeng Zhao <yifeng.zhao@rock-chips.com>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	"open list:ARM/Rockchip SoC..."
	<linux-rockchip@lists.infradead.org>,
	Collabora Kernel ML <kernel@collabora.com>
Subject: Re: renesas/master bisection: baseline-nfs.bootrr.rockchip-usb2phy0-probed on rk3399-gru-kevin
Date: Wed, 28 Jul 2021 09:48:02 +0100	[thread overview]
Message-ID: <2fc2b898-434c-3288-2052-70b1e1427b39@collabora.com> (raw)
In-Reply-To: <CAMuHMdUi_=xnvYFgiWXxSyrfoMn0JJCcH+TXFUh+1JUf=4u87A@mail.gmail.com>

On 28/07/2021 09:17, Geert Uytterhoeven wrote:
> Hi Guillaume et al,
> 
> On Wed, Jul 28, 2021 at 8:05 AM Guillaume Tucker
> <guillaume.tucker@collabora.com> wrote:
>> Please see the bisection report below about usb2phy failing to
>> probe on rk3399-gru-kevin.
>>
>> Reports aren't automatically sent to the public while we're
>> trialing new bisection features on kernelci.org but this one
>> looks valid.
> 
> Thanks for your report!
> 
>> The bisection was run in the Renesas tree but the same regression
>> is present in mainline for both usb2phy0 and usb2phy1 devices:
> 
> Exactly, the faulty commit is part of v5.14-rc1.
> 
>>> Breaking commit found:
>>>
>>> -------------------------------------------------------------------------------
>>> commit 8c3d64251ac5c5a3d10364f6b07d3603ac1e7b4a
>>> Author: Johan Jonker <jbx6244@gmail.com>
>>> Date:   Tue Jun 1 18:47:59 2021 +0200
>>>
>>>     arm64: dts: rockchip: rename nodename for phy-rockchip-inno-usb2
> 
> P.S. KernelCI is sending lots of reports to linux-reneas-soc[1] for
>      (a) issues on non-Renesas platforms[2], and

One thing to distinguish here is that changes in a tree like the
Renesas one might actually break other platforms, even if it
seems unlikely.  But the improvement explained below addresses
this issue.

>      (b) issues not originating in the renesas-devel tree, like this one.

That is just because I found the bisection report from the
Renesas tree before getting one from mainline.  As we're manually
triaging reports, I mentioned it in my email.  And you're right,
we would need to take this into account before having all the
bisection reports sent automatically.

> Suggestions for improvement:
>   1. If a regression is detected in an upstream tree, there is no
>      need to report it for downstream trees, unless it affects
>      the downstream tree, or originated there.

That's right, we're working on an improvement to be able to
detect "2nd order" regressions, that is to say new failures in a
branch relatively to new failures in an upstream branch.  That
would be typically mainline or stable, but sometimes a subsystem
specific one.

>   2. If a regression is detected for a platform, there is no need
>      to report it for different platform trees, unless it originated
>      there.
> 
> BTW, I do look at the reports for Renesas platforms, but usually I
> don't see what's wrong, and the same platform works fine locally.

Until this has been improved, maybe we can just stop sending
email reports to linux-reneas-soc if they're mostly noise.  The
bisections will still run and reports like this one are sent to
the people and lists who are related to the changes in the patch
rather than the git tree so it's always relevant to them.

> Note that yesterday and today I get "Error while loading data from the
> server (error code: 500). Please contact the website administrator".

Yes that's because the Mongo DB service keeps crashing.  It's a
sysadmin issue that should hopefully get resolved soon, sorry for
the inconvenience.


Thanks for your feedback.

Best wishes,
Guillaume

> [1] https://lore.kernel.org/linux-renesas-soc/?q=kernelci.org
> [2] https://lore.kernel.org/linux-renesas-soc/60ff86ff.1c69fb81.dfe6f.6a7c@mx.google.com/


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  parent reply	other threads:[~2021-07-28  8:48 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <61002766.1c69fb81.8f53.9f6a@mx.google.com>
2021-07-28  6:04 ` renesas/master bisection: baseline-nfs.bootrr.rockchip-usb2phy0-probed on rk3399-gru-kevin Guillaume Tucker
2021-07-28  6:04   ` Guillaume Tucker
2021-07-28  6:04   ` Guillaume Tucker
2021-07-28  8:17   ` Geert Uytterhoeven
2021-07-28  8:17     ` Geert Uytterhoeven
2021-07-28  8:17     ` Geert Uytterhoeven
2021-07-28  8:21     ` Geert Uytterhoeven
2021-07-28  8:21       ` Geert Uytterhoeven
2021-07-28  8:21       ` Geert Uytterhoeven
2021-07-28  8:48     ` Guillaume Tucker [this message]
2021-07-28  8:48       ` Guillaume Tucker
2021-07-28  8:48       ` Guillaume Tucker
2021-07-28  8:39   ` Robin Murphy
2021-07-28  8:39     ` Robin Murphy
2021-07-28  8:39     ` Robin Murphy
2021-07-28  8:59     ` Guillaume Tucker
2021-07-28  8:59       ` Guillaume Tucker
2021-07-28  8:59       ` Guillaume Tucker
2021-07-28  9:16       ` Marc Zyngier
2021-07-28  9:16         ` Marc Zyngier
2021-07-28  9:16         ` Marc Zyngier
2021-07-28  9:51         ` Annotation for dtbscheck to ignore a defect (Was: Re: renesas/master bisection: baseline-nfs.bootrr.rockchip-usb2phy0-probed on rk3399-gru-kevin) Heiko Stübner
2021-07-28  9:51           ` Heiko Stübner
2021-07-28  9:51           ` Heiko Stübner
2021-10-01 10:00           ` Guillaume Tucker
2021-10-01 10:00             ` Guillaume Tucker
2021-10-01 10:00             ` Guillaume Tucker
2021-10-01 16:12             ` Rob Herring
2021-10-01 16:12               ` Rob Herring
2021-10-01 16:12               ` Rob Herring

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2fc2b898-434c-3288-2052-70b1e1427b39@collabora.com \
    --to=guillaume.tucker@collabora.com \
    --cc=cnemo@tutanota.com \
    --cc=devicetree@vger.kernel.org \
    --cc=ezequiel@collabora.com \
    --cc=geert@linux-m68k.org \
    --cc=heiko@sntech.de \
    --cc=helen.koike@collabora.com \
    --cc=hjc@rock-chips.com \
    --cc=jacob2.chen@rock-chips.com \
    --cc=jbx6244@gmail.com \
    --cc=kernel@collabora.com \
    --cc=kernelci-results@groups.io \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=maccraft123mc@gmail.com \
    --cc=maz@kernel.org \
    --cc=robh+dt@kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=wens@csie.org \
    --cc=yifeng.zhao@rock-chips.com \
    --cc=zhangqing@rock-chips.com \
    --cc=zhengsq@rock-chips.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.