From: "Kahola, Mika" <mika.kahola@intel.com>
To: "Kahola, Mika" <mika.kahola@intel.com>,
"Latvala, Petri" <petri.latvala@intel.com>
Cc: "igt-dev@lists.freedesktop.org" <igt-dev@lists.freedesktop.org>
Subject: Re: [igt-dev] [PATCH i-g-t v3] tests/kms_concurrent: Move bandwidth calculation to igt_fixture
Date: Tue, 31 Mar 2020 10:12:31 +0000 [thread overview]
Message-ID: <8948cf46ed2a48c88e87c50b713e0c45@intel.com> (raw)
In-Reply-To: <fcb11df357404b83af8dade221c7047f@intel.com>
> -----Original Message-----
> From: igt-dev <igt-dev-bounces@lists.freedesktop.org> On Behalf Of Kahola,
> Mika
> Sent: Tuesday, March 31, 2020 11:22 AM
> To: Latvala, Petri <petri.latvala@intel.com>
> Cc: igt-dev@lists.freedesktop.org
> Subject: Re: [igt-dev] [PATCH i-g-t v3] tests/kms_concurrent: Move bandwidth
> calculation to igt_fixture
>
>
>
> -----Original Message-----
> From: Latvala, Petri <petri.latvala@intel.com>
> Sent: Tuesday, March 31, 2020 9:45 AM
> To: Kahola, Mika <mika.kahola@intel.com>
> Cc: igt-dev@lists.freedesktop.org; juhapekka.heikkila@gmail.com; Lisovskiy,
> Stanislav <stanislav.lisovskiy@intel.com>
> Subject: Re: [PATCH i-g-t v3] tests/kms_concurrent: Move bandwidth calculation
> to igt_fixture
>
> On Mon, Mar 30, 2020 at 02:02:29PM +0300, Mika Kahola wrote:
> > The commit 153b34b5353df8c18a87d ("tests/kms_concurrent:
> > Test maximum number of planes supported by the platform") caused
> > regression on HSW pipe B testing such as.
> >
> > IGT-Version: 1.25-gfd8248084 (x86_64) (Linux:
> > 5.6.0-rc7-CI-CI_DRM_8194+ x86_64) Starting subtest: pipe-B Testing
> > resolution with connector VGA-1 using pipe B with seed 1585245074
> > child 0 died with signal 11, Segmentation fault Subtest pipe-B: FAIL
> > (0.330s)
> >
> > To fix this, we need move bandwidth calculation routines into part of
> > igt_fixture instead of calculating it just before actual testing. The
> > patch takes the minimum of those maximum number of planes for given
> output.
> >
> > v2: Limit bandwidth check only gen11+ (CI)
> > v3: Loop child process 5x longer when running test with 1 iteration
> > (CI)
> >
> > Signed-off-by: Mika Kahola <mika.kahola@intel.com>
> > ---
> > tests/kms_concurrent.c | 30 ++++++++++++++++--------------
> > 1 file changed, 16 insertions(+), 14 deletions(-)
> >
> > diff --git a/tests/kms_concurrent.c b/tests/kms_concurrent.c index
> > 1403e990..31c5620a 100644
> > --- a/tests/kms_concurrent.c
> > +++ b/tests/kms_concurrent.c
> > @@ -36,6 +36,7 @@ typedef struct {
> > igt_display_t display;
> > igt_plane_t **plane;
> > struct igt_fb *fb;
> > + int max_planes;
> > } data_t;
> >
> > /* Command line parameters. */
> > @@ -223,13 +224,13 @@ test_plane_position_with_output(data_t *data,
> enum pipe pipe, int max_planes,
> > igt_output_t *output)
> > {
> > int i;
> > - int iterations = opt.iterations < 1 ? 1 : opt.iterations;
> > + int iterations = opt.iterations < 5 ? 1 : opt.iterations;
>
> This changes nothing though for CI. You still use 1. In fact this just limits the
> iterations to 1 for everyone who specifies more than 1, until they use 5 or more.
>
> And still, this patch needs an actual explanation why the crash happened and
> why doing the same calculation in a fixture help. Otherwise there's no guarantee
> it won't happen again. Until proven otherwise, avoiding the crash is accidental.
>
> I investigated this a bit further and I noticed that for yet unidentified reason the
> bandwidth calculation returned different number of planes for pipe B. This was
> too much to handle on actual test and therefore child exited too early.
>
> There seems to be a simpler way of computing how many planes we can support
> with the given bandwidth. I propose that we disregard this patch and I will
> propose and test another kind of solution.
What would be to best approach here? Should I first revert the original patch i.e.
commit 2b65609b1de3 ("tests/kms_concurrent: Test maximum number of planes supported by the platform")
and then provide a new patch that has similar functionality but the approach is different or should I just a provide a fix that removes bandwidth calculations and replaces that with a different approach?
-Mika-
>
> -Mika-
> --
> Petri Latvala
> _______________________________________________
> igt-dev mailing list
> igt-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/igt-dev
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev
next prev parent reply other threads:[~2020-03-31 10:12 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-30 11:02 [igt-dev] [PATCH i-g-t v3] tests/kms_concurrent: Move bandwidth calculation to igt_fixture Mika Kahola
2020-03-30 11:59 ` [igt-dev] ✓ Fi.CI.BAT: success for tests/kms_concurrent: Move bandwidth calculation to igt_fixture (rev4) Patchwork
2020-03-31 2:54 ` [igt-dev] ✗ Fi.CI.IGT: failure " Patchwork
2020-03-31 6:19 ` Kahola, Mika
2020-03-31 6:44 ` [igt-dev] [PATCH i-g-t v3] tests/kms_concurrent: Move bandwidth calculation to igt_fixture Petri Latvala
2020-03-31 6:51 ` Kahola, Mika
2020-03-31 8:22 ` Kahola, Mika
2020-03-31 10:12 ` Kahola, Mika [this message]
2020-03-31 11:04 ` Petri Latvala
2020-03-31 11:24 ` Kahola, Mika
2020-03-31 10:07 ` [igt-dev] ✓ Fi.CI.IGT: success for tests/kms_concurrent: Move bandwidth calculation to igt_fixture (rev4) Patchwork
2020-03-31 10:48 ` Patchwork
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=8948cf46ed2a48c88e87c50b713e0c45@intel.com \
--to=mika.kahola@intel.com \
--cc=igt-dev@lists.freedesktop.org \
--cc=petri.latvala@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox