- Jun 16, 2020
-
-
Arkadiusz Hiler authored
Since IGT is using magic control blocks (igt_subtest et al.) asserts jump out the them using longjmp() causing a bunch of confusing messages and occasionally crashing the whole process. This is not the behavior we want :-) With this patch: 1. simple_main, dynamic and subtest each clears the thread failure state at the start 2. each of those blocks also asserts no thread failures at the end 3. igt_assert() in non-main thread prints out the error + stacktrace and marks that we have failed thread Issue: drm/igt-gpu-tools#55 Signed-off-by:
Arkadiusz Hiler <arkadiusz.hiler@intel.com>
-
Arkadiusz Hiler authored
So that we know what's the source of messages. igt_thread.c is created to facilitate more threading-related functionality that will come in the following patch. Signed-off-by:
Arkadiusz Hiler <arkadiusz.hiler@intel.com>
-
- Jun 11, 2020
-
-
Ayaz Siddiqui authored
_open_pmu() was calling perf_igfx_open_group() which in turn was calling igt_perf_type_id("i915") each time. By making _open_pmu() take type as a parameter and call igt_perf_open_group() we achieve two things: * we use the correct type for engines->device instead of the hardcoded "i915" * optimization - we call igt_perf_type_id() once - it's reading sysfs Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Signed-off-by:
Ayaz A Siddiqui <ayaz.siddiqui@intel.com> Signed-off-by:
Arkadiusz Hiler <arkadiusz.hiler@intel.com> Reviewed-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com>
-
- Jun 10, 2020
-
-
Petri Latvala authored
__cancel_work_at_exit writes -1 to param "reset", with the intention that it's "any available method". Hex values to numeric params should be prefixed with 0x to be parsed as a number. Use the convention of %u with -1 as is used elsewhere with the "reset" param. Signed-off-by:
Petri Latvala <petri.latvala@intel.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk>
-
Arkadiusz Hiler authored
Sometimes creating the string representation fails. This usually happens when we have a huge logs (e.g.: something was spamming the dmesg) or the result generation was run on a very low-end system (e.g. embedded board with 256 megs of RAM). Sadly json-c call returns us NULL and provides no explanation whatsoever. Let's fix a NULL pointer dereference in such cases and print a mesage that should help people make sense out of what have just happened. Cc: Swati Sharma <swati2.sharma@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>
-
Petri Latvala authored
In commit b943d64f ("kms_atomic_transition: Make the available pipe discovery dynamic") the subtests of kms_atomic_transition were split into dynamic subtests. What avoided scrutiny however was that the looping uses for_each_pipe_with_valid_output, which gives you every valid pipe/output combo, so just using the pipe name as the dynamic subtest name causes duplicates, resulting in weird CI results. As the nature of the original test was a stress test for watermarks, keep the full combo rather than switching to for_each_pipe_with_single_output, but use the output name as well in the dynamic subtest name. Signed-off-by:
Petri Latvala <petri.latvala@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk>
-
- Jun 09, 2020
-
-
This allows the test to work on setups where the primary plane cannot be disabled while the CRTC is enabled. It should make no difference for the output. Signed-off-by:
Michel Dänzer <mdaenzer@redhat.com> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com>
-
- Jun 08, 2020
-
-
Arkadiusz Hiler authored
It got removed in Python 3.9 and ever since Python 3.3 it's: from xml.etree.ElementTree import * Link: https://docs.python.org/3.9/whatsnew/3.9.html#removed Issue: #86 (comment 520308) Cc: Petri Latvala <petri.latvala@intel.com> Cc: Lionel Landwerlin <lionel.g.landwerlin@linux.intel.com> Signed-off-by:
Arkadiusz Hiler <arkadiusz.hiler@intel.com> Reviewed-by:
Petri Latvala <petri.latvala@intel.com>
-
Ayaz Siddiqui authored
In intel_gpu_top device path was hard coded for integrated GPU. With this patch we: * use igt_device_scan library for device scanning, * make discrete GPU the default one, * provided options for card selection. v2: * explicitly set ret to EXIT_SUCCESS after all the other uses * fix use after free of opt_device (Tvrtko) * use EXIT_FAILURE instead of "1" (Tvrtko) Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Signed-off-by:
Ayaz A Siddiqui <ayaz.siddiqui@intel.com> Signed-off-by:
Arkadiusz Hiler <arkadiusz.hiler@intel.com> Reviewed-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com>
-
Ayaz Siddiqui authored
Will be used in the next patch. 1. set_pci_slot_name(): stores PCI_SLOT_NAME from prop to device 2. igt_device_find_first_discrete_card(): try to find first discrete GPU 3. igt_devices_free(): Free device buffers created during scan Signed-off-by:
Ayaz A Siddiqui <ayaz.siddiqui@intel.com> Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by:
Arkadiusz Hiler <arkadiusz.hiler@intel.com> Reviewed-by:
Petri Latvala <petri.latvala@intel.com>
-
Ayaz Siddiqui authored
igt_device_scan can now be used as a separate library which only depends glib and libudev - some IGT internals are being stubbed in this case. v2: (mostly) sort includes (Lucas) Cc: Lucas De Marchi <lucas.de.marchi@gmail.com> Signed-off-by:
Ayaz A Siddiqui <ayaz.siddiqui@intel.com> Signed-off-by:
Arkadiusz Hiler <arkadiusz.hiler@intel.com> Reviewed-by:
Petri Latvala <petri.latvala@intel.com>
-
Ayaz Siddiqui authored
Return value of udev_enumerate_add_match_property() was not being checked in scan_drm_devices(). Signed-off-by:
Ayaz A Siddiqui <ayaz.siddiqui@intel.com> Signed-off-by:
Arkadiusz Hiler <arkadiusz.hiler@intel.com> Reviewed-by:
Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com>
-
- Jun 07, 2020
-
-
Chris Wilson authored
Since preempt-reset is 640ms we have to wait at least that long to recover from a hostile client. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Acked-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com>
-
- Jun 06, 2020
-
-
Remove all "localized" functions in media spin and libdrm usage in the test. Signed-off-by:
Zbigniew Kempczyński <zbigniew.kempczynski@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk>
-
For some scenarios we want to keep previous objects and their offsets and recreate only batchbuffer object. To allow user do that add bb reset function which can or not purge collected objects from previous run. Signed-off-by:
Zbigniew Kempczyński <zbigniew.kempczynski@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk>
-
To avoid relocations when intel_buf is used we need to keep previous offset and context. Add addr structure with offset and ctx fields. Signed-off-by:
Zbigniew Kempczyński <zbigniew.kempczynski@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk>
-
- Jun 04, 2020
-
-
Imre Deak authored
After replugging a connector and the kernel reports the connector as connected the cached modes returned by drmModeGetConnectorCurrent() (the kernel's cached list of modes) may be stale. The modes will be only updated by a full reprobe. Ensure this by setting output->force_reprobe which will result in calling drmModeGetConnector(). This fixes sporadic test failures due to seeing no modes unexpectedly. So far things happened to work, because some in-kernel user of the output - like fbdev - does a full reprobe sometime after the hotplug event. Cc: Arkadiusz Hiler <arkadiusz.hiler@intel.com> Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
Arkadiusz Hiler <arkadiusz.hiler@intel.com>
-
Arkadiusz Hiler authored
If we fail to fork (e.g. due to restrictive limits) -1 gets written as PID of our child and we assert out. The cleanup that happens afterwards tries to kill all our children, which ends up in kill(-1, SIGKILL) which is not good. This patch makes sure of two things: * -1 doesn't get written down as our child * when we are killing children we make sure that pid > 0 Reported-by:
Fei Yang <fei.yang@intel.com> Cc: Michael Hebenstreit <michael.hebenstreit@intel.com> Cc: Petri Latvala <petri.latvala@intel.com> Signed-off-by:
Arkadiusz Hiler <arkadiusz.hiler@intel.com> Tested-by:
Michael Hebenstreit <michael.hebenstreit@intel.com> Reviewed-by:
Petri Latvala <petri.latvala@intel.com>
-
- Jun 03, 2020
-
-
The gem_create_v2 uapi was never merged, which would have been a nice addition to allow userspace to utilise stolen memory. Since it can only get in the way at this point, let's just remove it. Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk>
-
Chris Wilson authored
Disable the pre-parser on Tigerlake as we are dynamically rewriting the batches and so need to disable the parser cache. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com>
-
Petri Latvala authored
DRM logging in the kernel has switched to device based logging, changing the pattern of logging from [drm:function_name] Message to i915 0000:00:02.0: [drm] Message Change the pattern we use with --piglit-style-dmesg to match the new style logging, catching all warnings that contain [drm]. We're no longer result-wise exactly piglit compatible but then again that ship sailed long time ago with the change of introducing dmesg-level parameter. Piglit compatibility result-wise is not a goal regardless. Signed-off-by:
Petri Latvala <petri.latvala@intel.com> Cc: Arkadiusz Hiler <arkadiusz.hiler@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by:
Jani Nikula <jani.nikula@intel.com>
-
- Jun 02, 2020
-
-
José Roberto de Souza authored
This tests is being sporadically skipped in CI as it is not due "PSR sink not reliable: yes" lets print the i915_edp_psr_status to find out the reason. This can be reverted afterwards. Reference: https://gitlab.freedesktop.org/drm/intel/-/issues/1911 Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Reviewed-by:
Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by:
José Roberto de Souza <jose.souza@intel.com>
-
José Roberto de Souza authored
Not sure why but in recent kernels + IGT when PSR status debugfs is read the frame already passed, so the su blocks is set in frame 1 and causing the test to fail for page flips. So here reading from frame 1 if frame 0 has 0 blocks, as this test always changes screen with the same number of su blocks it is not a issue. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/608 Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Reviewed-by:
Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by:
José Roberto de Souza <jose.souza@intel.com>
-
- Jun 01, 2020
-
-
José Roberto de Souza authored
If by some reason or tests, this tests is executed and VT mode is already in KD_GRAPHICS the call to kmstest_set_vt_graphics_mode() will set orig_vt_mode as KD_GRAPHICS and when it was calling kmstest_restore_vt_mode() it would set KD_GRAPHICS again not returning to fbcon and causing the test to fail. As it can be seen here: (kms_fbcon_fbt:11004) igt_kms-DEBUG: VT: graphics mode set (mode was 0x1)" https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_499/fi-ehl-1/igt@kms_fbcon_fbt@fbc.html So here adding a new function to alaways set mode the KD_TEXT when we want to restore to fbcon. Reviewed-by:
Uma Shankar <uma.shankar@intel.com> Signed-off-by:
José Roberto de Souza <jose.souza@intel.com>
-
Remove libdrm functions and replace them with new ones after removing _v2 suffix introduced for transition state. Signed-off-by:
Zbigniew Kempczyński <zbigniew.kempczynski@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk>
-
To allow remove "_v2" suffix in functions add this not-fully-clean step and localize names. Some additional requirement is needed to fulfill its needs (passing batchbuffer from the caller side). Signed-off-by:
Zbigniew Kempczyński <zbigniew.kempczynski@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk>
-
Imre Deak authored
After Chamelium does an FSM signaling by deasserting its HPD, in response to which the test's FSM handler disables the output with a DPMS-off, we have to make sure that Chamelium has reasserted its HPD before we re-enable the output with DPMS-on (for instance to avoid link training errors, or enable the output in the wrong TypeC mode). To ensure this wait for the connector state to become asserted. On TypeC connectors with an enabled mode the IOM firmware will signal a connected state (via a connect hotplug interrupt delivered to the driver) in a deferred way only after the mode is disabled. So wait for the connected state after DPMS-off. Reported-and-tested-by:
Kunal Joshi <kunal1.joshi@intel.com> Cc: Hiler Arkadiusz <arkadiusz.hiler@intel.com> Cc: Kunal Joshi <kunal1.joshi@intel.com> Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
Arkadiusz Hiler <arkadiusz.hiler@intel.com>
-
- May 31, 2020
-
-
Chris Wilson authored
Be careful and check the engine support store-dw as we are using __igt_spin_new() which skips the requirement checks. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Acked-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com>
-
Chris Wilson authored
The test works fine if the scheduler has semaphores, strangely only being skipped for old devices adding semaphore support. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Acked-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com>
-
Chris Wilson authored
Can't test queues, if we don't have queues. The queue ordering tests checked for scheduler support, assuming that would mean we had full-ppgtt. Check for queues in case we solve the scheduler problem on gen6/gen7. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Acked-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com>
-
Chris Wilson authored
Add a pass that imposes a delay between submitting the master and its bonded pair. This should make it more likely that another thread is able to submit in the interval. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Acked-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com>
-
Chris Wilson authored
Since we create a few GPU objects in the locals, if we decided to skip this bonded-sync phase, we need to jump to the cleanup. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Acked-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com>
-
Chris Wilson authored
Add another bonded-runner variant for a pair of inter-locked non-preemptible waiters (each batch waits to be cancelled by the other), as we are trying to replicate the HW feature where a bonded pair is locked on HW and cannot be preempted until all members of the bond have executed (i.e. all must execute in lockstep). The key difference with this variant is that both halves contain a non-preemptible spin until the other half has executed. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Acked-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com>
-
- May 29, 2020
-
-
Chris Wilson authored
Randomly submit a paired spinner and its cancellation as a bonded (submit fence) pair. Apply congestion to the engine with more bonded pairs to see if the execution order fails. If we prevent a cancellation from running, then the spinner will remain spinning forever. v2: Test both immediate submission and fenced submission v3: Copy-n-paste a single context variant Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com>
-
- May 28, 2020
-
-
Chris Wilson authored
For determining whether or not we flip too fast, we don't have to wait long, just long enough. A ballpark measure of how long is reasonable is given by how fast we perform the warmup, as that is 3 flips/modesets. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Acked-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com>
-
Non-preemptible spinners should be avoided as often as possible. gem_exec_fence@[basic-await, nb-await] has no reason to use non-preemptible workload, only hanging subtests need it. Signed-off-by:
Dominik Grzegorzek <dominik.grzegorzek@intel.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk>
-
Chris Wilson authored
If we are using GPU relocations, then the batch may legitimately be marked as having been written to by the GPU. As this is expected, remove the write marker, which may be a different engine to that we execute on, and the corresponding read engine if different. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Acked-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com>
-
- May 27, 2020
-
-
Chris Wilson authored
Actually remember to unplug to the busy buffer after waiting for the flip to complete early. Otherwise we wait for the hangcheck to kick in, which while effective at testing the flip recovery for hanging buffers is not the intent of the test and wastes 40s in BAT. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Acked-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com>
-
- May 26, 2020
-
-
Chris Wilson authored
The hangcheck/reset modparam has far reaching effects and disables functionality if switch off. This can surprise a few tests causing them to skip. References: https://gitlab.freedesktop.org/drm/intel/-/issues/1929 Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Acked-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com>
-
Chris Wilson authored
gem_ring_measure_inflight() uses the legacy ring idx, whereas gem_exec_schedule is using the new dynamic ctx->engine[] indices. Mismatch and hanging tests ensue. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Acked-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com>
-