* Misc bikeshedding on test
* Fix test so we _always_ run at least one pass, even if that puts us
  slightly above the specified duration
* Add a benchmark mode. It turns out that trying to test vbl worker
  performance is quite error prone, but being able to stress test lut
  updates as quickly as possible makes this a lot easier.

Ville Syrjälä authored 5 years ago and Lyude Paul committed 5 years ago

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>

Petri Latvala authored 5 years ago and Chris Wilson committed 5 years ago

One missing fdatasync() for starting a subtest.

Fixes: drm/igt-gpu-tools#81


Signed-off-by: Petri Latvala <petri.latvala@intel.com>
Cc: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

Instead of repeating every single time we overflow the read from kmsg,
just once per test is enough warning.

v2: Just suppress the multiple s/underflow/overflow/ messages. Having a
buffer smaller than a single kmsg packet is unlikely.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Petri Latvala <petri.latvala@intel.com>
Reviewed-by: Petri Latvala <petri.latvala@intel.com>

Minor ABI break in reporting a new error code for a self-inflicted user
overlap within an execbuf.

References: 2920bb94e65f ("drm/i915: Drop inspection of execbuf flags during evict")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>

Sandybridge's rc6p while only consuming half the power of rc6, still
consumes a non-zero power. It appears Ivybridge was the first platform
to achieve negligible power draw (at least reported by the GPU) while in
rc6p (and later platforms in rc6). So exclude Sandybridge from
generating a warning as we have no hope of fixing.

Closes: https://gitlab.freedesktop.org/drm/intel/issues/1518


Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>

Allow the kernel the rights to reject updating an active VM with -EBUSY.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

The legacy ringbuffer submission lacks a fast soft-rc6
mechanism as we have no interrupt for an idle ring. As such
we are at the mercy of HW RC6... which is not quite as
precise as we need to pass this test. Oh well.

Since HW is not fast enough to minimise power draw, tell the driver to
park as soon as we know we are idle. One day, we hope for the driver to
discover a mechanism to do this for itself, for as this test shows that
can save us Watts!

Closes: https://gitlab.freedesktop.org/drm/intel/issues/1516


Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Andi Shyti <andi.shyti@intel.com>

The energy measurement is not the main focus of the test, although it is
important that we do minimise it. As that is not so critical make the
assertion into a warning, so that we do check the mostly idle rc6/energy
consumption.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>

All the I2C errors we get from chameleond happen when it is talking the
receiver and seem to have nothing to do with the HDMI/DisplayPort
upstream.

This seems to happen quite often after a reset when the receiver is not
yet ready for action.

Let's keep on knocking for 10s before finally giving up and settling on
an error.

v2: igt_until_timeout() (Petri)

Fixes: https://gitlab.freedesktop.org/drm/intel/issues/217
Issue: https://bugs.chromium.org/p/chromium/issues/detail?id=993738


Cc: Imre Deak <imre.deak@intel.com>
Cc: Kunal Joshi <kunal1.joshi@intel.com>
Cc: Petri Latvala <petri.latvala@intel.com>
Signed-off-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
Reviewed-by: Petri Latvala <petri.latvala@intel.com>

Give the driver every opportunity to sleep before we start waiting for
it to be in rc6, so it has absolutely no excuse to be leaking power
during the initial tests.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>

Since dynamic subtests we run multiple subtests in one binary, we
encounter situations where a bug in one subtest percolates into the next
subtest. Explicitly cleanup before each test to disarm our own shotgun.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>

Since we execute a few smokers in parallel, at worst we may have to wait
for all smokers to be reset before we ourselves are. We need to increase
our leniency for the smoketest and allow a longer timeout to accommodate
the parallelism.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>

Since the rc6-idle doesn't require the sysfs interface, we can run it
outside of the accuracy subgroup with much reduced requirements.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>

Use gem_sync() to trigger the waitboost, currrently we use a busywait to
avoid the frequency boost, to create a new test to make sure that our
waitboost does not impact upon idling.

We can use this test to demonstrate the impact of forgetting to cancel
the waitboost due to sleeping regularly.

References: https://gitlab.freedesktop.org/drm/intel/issues/1500


Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>

The driver can emit multiple hotplug events in response to a hotplug
interrupt, which may cause tests fail receiving a spurious early hotplug
event and concluding that an expected state didn't get set. Let's use
Arek's idea and wait for multiple hotplug events - with the current 20s
timeout - rechecking if the expected state got set after each hotplug.

The reasons for multiple hotplug events I noticed are:
- Both a get connector IOCTL and an HPD interrupt can generate a hotplug
  event.
- Resetting chamelium results in an intermittent state where HPD gets
  asserted, generating a hotplug connect uevent, then HPD gets
  deasserted generating the expected hotplug disconnect uevent.

Suggested-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>

Using chamelium as a display for non-chamelium-aware test is
challenging. The board can be left in multiple different states after
kms_chamelium tests even though we have atexit() handlers and other
measures which try to assure that all ports are plugged in. Sadly this
is not 100% reliable. We also had a few boards hard hanging (happens
very seldom) and requiring manual intervention.

This leads to changes in the testing configuration - we may end up with
any number of connectors plugged in which makes a lot of kms_ tests to
flip between skip and pass depending on a run.

In an attempt to make connectors state less random this patch makes
igt_display_require() chamelium-aware. If chamelium is configured for
given machine we try to reach it and make sure everything is plugged in.
If we fail to do so we abort the execution because the testing
configuration is an unknown.

For machines without a configured chamelium this boils down to a nop.

I have run a bunch of tests and measured how much time we spend in the
Chamelium section of igt_display_require() (n = 1000) with chamelium
configured:

    Min: 0.0030s     Max:    0.0113s
    Avg: 0.0089s     Median: 0.0089s

With ~1000 of KMS subtests in a run it's only a mere 9s.

This will however add a bit of extra execution time to test skips
because of doing kmstest_set_vt_graphics_mode() and
igt_display_require() before even checking whether Chamelium is
configured.

v2: do kmstest_set_vt_graphics_mode() before requiring display (Petri)

Fixes: drm/igt-gpu-tools#20


Signed-off-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
Reviewed-by: Petri Latvala <petri.latvala@intel.com>

Let's extract the bit that reads the config and initializes xmlrpc so we
can do some basic things with chamelium without the need to do port
auto-discovery and connector mapping.

Signed-off-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
Reviewed-by: Petri Latvala <petri.latvala@intel.com>

chamelium_wait_reachable() is asserting internally if the chamelium not
reachable. Let's make it return bool instead and create
void chamelium_assert_reachable() that fails the run.

v2: Add docs (Petri)

Signed-off-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
Reviewed-by: Petri Latvala <petri.latvala@intel.com>

Otherwise this may get us stuck in perpetual failure mode.

Signed-off-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
Reviewed-by: Petri Latvala <petri.latvala@intel.com>

Now that the IGT tests have a mechanism for signaling broken testing
conditions we can stop the run on the first test that has noticed it,
and possibly has triggered that state.

Traditionally run would have continued with that test failing and the
side effects would trickle down into the other tests causing a lot of
skip/fails.

v2: extra explanations, small cleanup (Petri)

Signed-off-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
Reviewed-by: Petri Latvala <petri.latvala@intel.com>

to make this bit of code more readable and to reuse it in the following patch

Signed-off-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
Reviewed-by: Petri Latvala <petri.latvala@intel.com>

igt_abort_on_f() is introduced which does very little cleanup and causes
a hard exit() of the test binary with a unique exit code
(IGT_EXIT_ABORT).

The exit code informs the monitoring process that there is a critical
issue with the testing environment which may have an impact on the
results if testing continues.

v2: Add a meta_test

Signed-off-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
Reviewed-by: Petri Latvala <petri.latvala@intel.com>

Trying to read interleaved writes is a bit tricky, so let's just use
/dev/null if we care about contents on only one of those pipes.

Signed-off-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
Reviewed-by: Petri Latvala <petri.latvala@intel.com>

Because of excessive 'copy and paste' we ended up with multiple copies
of almost the same fork helper. This patch extracts the do_fork helper
out and switches all the tests over to it.

Additionally, preemptively I have extracted the more fancy fork helper
that captures stderr/out + related functions out of igt_describe tests.

Signed-off-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
Reviewed-by: Petri Latvala <petri.latvala@intel.com>

Change test initialization so CRC buffer will not become full
on slower machines.

v2: don't waste time by draining crcs unnecessarily.

Signed-off-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>

In some cases we ran out of bandwidth when executiong a test.
An error such as this can be seen on dmesg

"Bandwidth 16632 MB/s exceeds max available 6553 MB/s (7 active planes)"

The patch tests first, how many planes the platform can support with
the given resolution. The actual test is then performed by using the
calculated maximum number of planes instead of maximum number of planes
that the platform supports.

Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>

Signed-off-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
Acked-by: Petri Latvala <petri.latvala@intel.com>

Lyude Paul authored 5 years ago and Petri Latvala committed 5 years ago

Now that we've fixed a bunch of build breakages on systems where
-fcommon is the default (gcc 10+), let's start building with -fcommon by
default so we can make sure things don't break with this in the future.
Supposedly it's supposed to be able to generate better code anyway!

Signed-off-by: Lyude Paul <lyude@redhat.com>
Acked-by: Petri Latvala <petri.latvala@intel.com>

Lyude Paul authored 5 years ago and Petri Latvala committed 5 years ago

Another spot where we fail compilation with -fcommon, due to src_operand
getting included in multiple translation units without being marked as
extern:

/usr/bin/ld:
assembler/1ca89e8@@intel-gen4asm@exe/meson-generated_gram.c.o:assembler/gen4asm.h:119:
multiple definition of `src_operand';
assembler/1ca89e8@@intel-gen4asm@exe/meson-generated_lex.c.o:assembler/gen4asm.h:119:
first defined here
/usr/bin/ld:
assembler/1ca89e8@@intel-gen4asm@exe/main.c.o:assembler/gen4asm.h:119:
multiple definition of `src_operand';
assembler/1ca89e8@@intel-gen4asm@exe/meson-generated_lex.c.o:assembler/gen4asm.h:119:
first defined here

However, we never actually refer to this variable - only its type
definition. So, just remove the declaration entirely.

Changes since v1:
* Don't make src_operand extern - just remove the variable declaration
  entirely, we only ever use the typedef - Chris Wilson

Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Petri Latvala <petri.latvala@intel.com>

Lyude Paul authored 5 years ago and Petri Latvala committed 5 years ago

We currently manually specify the name of the source file by-hand here,
however this causes problems if the user tries to build with compile
flags like -fdebug-prefix-map since the source file names will then
differ from what's hardcoded here - causing tests to fail.

So, fix that by using __FILE__ instead.

Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Petri Latvala <petri.latvala@intel.com>

In case of error creating a context, the error is returned without
updating the context outparam. Initialise it so we don't destroy
garbage.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>