Skip to content
Snippets Groups Projects
  1. Feb 27, 2023
  2. Feb 24, 2023
    • Kamil Konieczny's avatar
      i915/i915_suspend: run in subprocess to catch oom · deab4e0b
      Kamil Konieczny authored
      
      Shrink subtest can end up with oom killing it. Create subprocess
      and run it from there so it will at least get reported like:
      
      dynamic child 0 pid:70254 died with signal 9, Killed
      Subtest shrink: FAIL (23.906s)
      
      dmesg reports:
      
      [103335.337309] Out of memory: Killed process 70254 (i915_suspend)
      
      Cc: Riana Tauro <riana.tauro@intel.com>
      Cc: Anshuman Gupta <anshuman.gupta@intel.com>
      Signed-off-by: default avatarKamil Konieczny <kamil.konieczny@linux.intel.com>
      Reviewed-by: default avatarSai Gowtham Ch <sai.gowtham.ch@intel.com>
      deab4e0b
    • Janusz Krzysztofik's avatar
      tests/i915_suspend: Refresh device list after *-without-i915 subtests · 71496b0d
      Janusz Krzysztofik authored
      
      If any of *-without-i915 subtests fails or skips for any reason, it may
      leave the i915 module unloaded while keeping our device list populated
      with initially collected data.  In a follow up igt_fixture section we then
      try to reopen the device.  If the test has been executed with a device
      filter specified, an attempt to open the device finds a matching entry
      that belongs to the no longer existing device in that initially collected
      device list, fails to stat() it, concludes that's because of the device
      having been already open, and returns an error.  While that error,
      triggered after subtests completion, doesn't affect results of the
      subtest, reported by CI togethger with those results it is confusing to
      users reviewing those reports.
      
      Fix this issue by refreshing the potentially outdated device list before
      continuing with drm_open_driver() if we've been called with a device
      filter specified.
      
      While being at it, add a comment that explains why we call
      igt_devices_scan() from __igt_device_card_match() but don't force device
      rescan, and emit a debug message if we fail in _is_already_opened() on
      unsuccessful device stat().
      
      v2: don't free the device list -- we can't tell if it has been populated,
          and igt_devices_free() fails if it hasn't,
        - commit message updated, description improved.
      
      Subtest basic-s3-without-i915: FAIL (9.572s)
      (i915_suspend:9050) drmtest-WARNING: card maching filter 0 is already opened
      (i915_suspend:9050) drmtest-CRITICAL: Test abort in function drm_open_driver, file ../lib/drmtest.c:639:
      (i915_suspend:9050) drmtest-CRITICAL: abort condition: fd < 0
      (i915_suspend:9050) drmtest-CRITICAL: Last errno: 2, No such file or directory
      (i915_suspend:9050) drmtest-CRITICAL: No known gpu found for chipset flags 0x1 (intel)
      Test i915_suspend failed.
      **** DEBUG ****
      (i915_suspend:9050) drmtest-DEBUG: Looking for devices to open using filter 0: pci:vendor=intel,device=dg2
      (i915_suspend:9050) drmtest-DEBUG: Filter matched /dev/dri/card0 | /dev/dri/renderD128
      (i915_suspend:9050) drmtest-WARNING: card maching filter 0 is already opened
      (i915_suspend:9050) drmtest-CRITICAL: Test abort in function drm_open_driver, file ../lib/drmtest.c:639:
      (i915_suspend:9050) drmtest-CRITICAL: abort condition: fd < 0
      (i915_suspend:9050) drmtest-CRITICAL: Last errno: 2, No such file or directory
      (i915_suspend:9050) drmtest-CRITICAL: No known gpu found for chipset flags 0x1 (intel)
      (i915_suspend:9050) igt_core-INFO: Stack trace:
      (i915_suspend:9050) igt_core-INFO:   #0 ../lib/igt_core.c:2066 __igt_abort()
      (i915_suspend:9050) igt_core-INFO:   #1 ../lib/drmtest.c:573 drm_open_driver()
      (i915_suspend:9050) igt_core-INFO:   #2 ../tests/i915/i915_suspend.c:258 __igt_unique____real_main245()
      (i915_suspend:9050) igt_core-INFO:   #3 ../tests/i915/i915_suspend.c:245 main()
      (i915_suspend:9050) igt_core-INFO:   #4 ../sysdeps/nptl/libc_start_call_main.h:58 __libc_start_call_main()
      (i915_suspend:9050) igt_core-INFO:   #5 ../csu/libc-start.c:128 __libc_start_main@@GLIBC_2.34()
      (i915_suspend:9050) igt_core-INFO:   #6 [_start+0x2a]
      ****  END  ****
      
      Fixes: f7aff600 ("tests/i915/i915_suspend: Disable d3cold_allowed for basic-s2idle-without-i915")
      Signed-off-by: default avatarJanusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
      Cc: Riana Tauro <riana.tauro@intel.com>
      Link: https://patchwork.freedesktop.org/patch/522501/
      
      
      Reviewed-by: default avatarKamil Konieczny <kamil.konieczny@linux.intel.com>
      71496b0d
  3. Feb 23, 2023
  4. Feb 21, 2023
  5. Feb 20, 2023
  6. Feb 17, 2023
    • Zack Rusin's avatar
      lib/igt_kmod: Switch warning to an info when not using i915 · 509e7e63
      Zack Rusin authored and Kamil Konieczny's avatar Kamil Konieczny committed
      
      Because igt always tries to load i915 driver first for DRIVER_ANY every
      test using DRIVER_ANY on anything but i915 starts by printing a warning
      that i915 couldn't be loaded.
      Lets switch it to a general info line because it makes it hard to spot
      actual warnings when every subtest starts by warning about not being
      able to load i915.
      
      v1: changed commit title to lib/igt_kmod (Kamil)
      
      Signed-off-by: default avatarZack Rusin <zackr@vmware.com>
      Acked-by: default avatarPetri Latvala <petri.latvala@intel.com>
      509e7e63
    • Christopher Snowhill's avatar
      intel_gpu_top: Add display name for compute engine class · e4e7d350
      Christopher Snowhill authored and Kamil Konieczny's avatar Kamil Konieczny committed
      
      Add label and abbreviated display name for the compute engine class.
      
      Signed-off-by: default avatarChristopher Snowhill <kode54@gmail.com>
      Reviewed-by: default avatarKamil Konieczny <kamil.konieczny@linux.intel.com>
      e4e7d350
    • Janusz Krzysztofik's avatar
      tests: Exercise remote request vs barrier handling race · a3ef8a60
      Janusz Krzysztofik authored
      Users reported oopses on list corruptions when using i915 perf with a
      number of concurrently running graphics applications.  That indicates we
      are currently missing some important tests for such scenarios.  Cover
      that gap.
      
      Root cause analysis pointed out to an issue in barrier processing code and
      its interaction with perf replacing kernel contexts' active barriers with
      its own requests.
      
      Add a new test intended for exercising intentionally racy barrier tasks
      list processing and its interaction with other i915 subsystems.  As a
      first subtest, add one that exercises the interaction of remote requests
      with barrier tasks list handling, especially barrier preallocate / acquire
      operations performed during context first pin / last unpin.
      
      The code is partially inspired by Chris Wilson's igt@perf@open-race
      subtest, which I was not able to get an Ack for from upstream.
      
      v4: fix typo in test description and make it generic so it will not need
          to be changed soon (Kamil),
        - rename workload functions instead of providing name wrappers (Kamil),
        - no need for all physical engines to be tested (Kamil).
      v3: don't add the new subtest to gem_ctx_exec which occurred blocklisted,
          create a new test hosting the new subtest, update commit descripion,
        - prepare parameters for perf open still in the main thread to avoid
          test failures on platforms with no perf support (will skip now),
        - call perf open with OA buffer reports disabled, this will make sure
          that the perf API doesn't unnecessarily enable the OA unit, while the
          test still runs the targeted code (Umesh),
        - replace additional code for OA exponent calculations with a reasonable
          hardcoded value (Umesh).
      v2: convert to a separate subtest, not a variant of another one (that has
          been dropped from the series),
        - move the subtest out of tests/i915/perf.c (Ashutosh), add it to
          tests/i915/gem_ctx_exec.c,
        - don't touch lib/i915/perf.c (Umesh, Ashutosh), duplicate reused code
          from tests/i915/perf.c in tests/i915/gem_ctx_exec.c.
      
      References: https://gitlab.freedesktop.org/drm/intel/-/issues/6333
      Cc: Chris Wilson <chris.p.wilson@intel.com>
      Cc: Ashutosh Dixit <ashutosh.dixit@intel.com>
      Cc: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
      Link: https://patchwork.freedesktop.org/patch/522916/
      
      
      [janusz: close fd on exit from intel_context_first_pin_last_unpin_loop]
      Reviewed-by: default avatarKamil Konieczny <kamil.konieczny@linux.intel.com>
      Signed-off-by: default avatarJanusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
      a3ef8a60
    • Swati2 Sharma's avatar
      tests/kms_plane_scaling: Add downscaling+upscaling tests · 63edb0c5
      Swati2 Sharma authored
      
      In newer hardware versions (i.e. display version >= 14), the second
      scaler doesn't support downscaling. Current driver design in the
      case of 2 plane scaling scenario is if plane1-US and plane2-DS,
      it's reject for now. That's why new tests are added for plane1-DS
      and plane2-US, so that different DS+US combinations can be validated.
      
      v2: -minor fix
      v3: -change from if-else ladder to switch (JP)
      
      Signed-off-by: default avatarSwati Sharma <swati2.sharma@intel.com>
      Reviewed-by: default avatarJuha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
      63edb0c5
  7. Feb 16, 2023
  8. Feb 13, 2023
  9. Feb 11, 2023
  10. Feb 10, 2023
  11. Feb 09, 2023
Loading