- 17 Mar, 2020 2 commits
-
-
Chris Wilson authored
Beware that the context may already be closed as we try to lookup an engine. Closes: https://gitlab.freedesktop.org/drm/intel/issues/1389 Fixes: 130a95e9 ("drm/i915/gem: Consolidate ctx->engines[] release") Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200316161447.18410-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
Apparently we do try and attach a fence to an invalid vma (during execbuf) so we cannot simply assert it never happens and report EINVAL instead. Fixes: dec9cf9e ("drm/i915/gt: Pull restoration of GGTT fences underneath the GT") Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200316205450.15843-1-chris@chris-wilson.co.uk
-
- 16 Mar, 2020 4 commits
-
-
Chris Wilson authored
Since the number of fence regs can vary dramactically between platforms, allocate the array on demand so we don't waste as much space. Signed-off-by:
-
Chris Wilson authored
Since we always reload the fence register state on runtime resume, having it explicitly in the S0ix resume code is redundant. Indeed, it is not even being used! Signed-off-by:
-
Chris Wilson authored
Make the GT responsible for restoring its fence when it wakes up from suspend. Signed-off-by:
-
Chris Wilson authored
Since the fence registers control HW detiling through the GGTT aperture, make them a part of the intel_ggtt under gt/ Signed-off-by:
-
- 15 Mar, 2020 1 commit
-
-
Chris Wilson authored
The residual w/a batch is causing system instablity on Ivybridge and Baytrail under some workloads, so disable until resolved. Closes: https://gitlab.freedesktop.org/drm/intel/issues/1405 Fixes: 47f8253d ("drm/i915/gen7: Clear all EU/L3 residual contexts") Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200311103640.26572-1-chris@chris-wilson.co.uk
-
- 14 Mar, 2020 1 commit
-
-
Rodrigo Vivi authored
Signed-off-by:
-
- 13 Mar, 2020 8 commits
-
-
José Roberto de Souza authored
We have a few TGL machines in our CI and it is mostly green with failures in tests that will not impact future Linux installations. Also there is no warnings, errors, flickering or any visual defects while doing ordinary tasks like browsing and editing documents in a dual monitor setup. As a reminder i915.require_force_probe was created to protect future Linux installation's iso images that might contain a kernel from the enabling time of the new platform. Without this protection most of linux installation was recommending nomodeset option during installation that was getting stick there after installation. Reference: https://intel-gfx-ci.01.org/tree/drm-tip/fi-tgl-u.html Reference: https://intel-gfx-ci.01.org/tree/drm-tip/shard-tglb.html Cc: James Ausmus <james.ausmus@intel.com> Cc: Jani Saarinen <jani.saarinen@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by:
José Roberto de Souza <jose.souza@intel.com> Acked-by:
Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200218230822.66801-1-jose.souza@intel.com
-
Matt Roper authored
This workaround appears under two different numbers (and with somewhat confused stepping applicability on ICL). Ultimately it appears we should just implement this for all stepping of ICL and EHL. Note that this is identical to Wa_1407928979:tgl that already exists in our driver too...yet another number referencing the same actual workaround. Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200311162300.1838847-7-matthew.d.roper@intel.comReviewed-by:
-
Matt Roper authored
The register this workaround updates is a render engine register in the MCR range, so we should initialize this in rcs_engine_wa_init() rather than gt_wa_init(). Closes: https://gitlab.freedesktop.org/drm/intel/issues/1222 Fixes: 36204d80 ("drm/i915/icl: Wa_1406680159") Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Signed-off-by:
-
Matt Roper authored
v2: - Move to context workarounds. ROW_CHICKEN4 is part of the context image on gen11 (although it isn't on gen12). Signed-off-by:
-
Matt Roper authored
The bspec description for this workaround tells us to program 0xFFFF_FFFF into both FBC_RT_BASE_ADDR_REGISTER_* registers, but we've previously found that this leads to failures in CI. Our suspicion is that the failures are caused by this valid turning on the "address valid bit" even though we're intentionally supplying an invalid address. Experimentation has shown that setting all bits _except_ for the RT_VALID bit seems to avoid these failures. v2: - Mask off the RT_VALID bit. Experimentation with CI trybot indicates that this is necessary to avoid reset failures on BCS. v3: - Program RT_BASE before RT_BASE_UPPER so that the valid bit is turned off by the first write. (Chris) Bspec: 11388 Bspec: 33451 Signed-off-by:
-
Matt Roper authored
On gen11 the XY_FAST_COPY_BLT command has some size restrictions on its usage. Although this instruction is mainly used by userspace, i915 also uses it to copy object contents during some selftests, so let's ensure the restrictions are followed. Bspec: 6544 Signed-off-by:
-
Matt Roper authored
The bspec documents multiple MCR ranges; make sure they're all captured by the driver. Bspec: 13991, 52079 Fixes: 592a7c5e ("drm/i915: Extend non readable mcr range") Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Signed-off-by:
-
Chris Wilson authored
Throw in the inverse patterns to create more examples of poison to use against the LRC state. Signed-off-by:
-
- 12 Mar, 2020 5 commits
-
-
Caz Yokoyama authored
This reverts commit 36a6b5d9. The commit takes care Wa_1604544889 which was fixed on a0 stepping based on a0 replan. So no SW workaround is required on any stepping now. Reviewed-by:
Caz Yokoyama <caz.yokoyama@intel.com> Signed-off-by:
-
Chris Wilson authored
During driver unload, we have many asserts that we have released our bookkeeping structs and are idle. In some cases, these struct are protected by RCU and we do not release them until after an RCU grace period. Reported-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Fixes: 130a95e9 ("drm/i915/gem: Consolidate ctx->engines[] release") Signed-off-by:
-
Chris Wilson authored
Switch igt_vm_isolation() to using igt_random_offset(). Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200312154708.1720-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
Since the relocations are no longer performed under a global struct_mutex, or any other lock, that is also held by pagefault handlers, we can relax and allow our fast path to take a fault. As we no longer need to abort the fast path for lock avoidance, we no longer need the slow path handling at all. Signed-off-by:
-
Tvrtko Ursulin authored
Allow super long OpenCL workloads which cannot be preempted within the default timeout to run out of the box. v2: * Make it stick out more and apply only to RCS. (Chris) v3: * Mention platform override in kconfig. (Joonas) Signed-off-by:
Michal Mrozek <Michal.mrozek@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200312115748.29970-1-tvrtko.ursulin@linux.intel.com
-
- 11 Mar, 2020 16 commits
-
-
Chris Wilson authored
When applying the context-barrier, we only care about the current engines, as the next set of engines will be naturally after the barrier. So we can skip holding the ctx->engines_mutex while constructing the request by taking a sneaky reference to the i915_gem_engines instead. Signed-off-by:
-
Chris Wilson authored
The sw-fence notify function requires to be at least 4-byte aligned so that we can use the low bits in the function pointer for internal fence flags. Make it so. References: https://gitlab.freedesktop.org/drm/intel/issues/1433 Fixes: 42fb60de ("drm/i915/gem: Don't leak non-persistent requests on changing engines") Signed-off-by:
-
Kai Vehmanen authored
Gen12 hardware supports HDMI audio pixel clocks of 296.7/297Mhz and 593.4/594Mhz. Add the missing rates and add logic to ignore them if running on older hardware. Bspec: 49333 Signed-off-by:
Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Chris Wilson authored
[11057.642683] BUG: KCSAN: data-race in i915_gem_mmap [i915] / singleton_release [i915] [11057.642717] [11057.642740] write (marked) to 0xffff8881f24471a0 of 8 bytes by task 44668 on cpu 2: [11057.643162] singleton_release+0x38/0x60 [i915] [11057.643192] __fput+0x160/0x3c0 [11057.643217] ____fput+0x16/0x20 [11057.643241] task_work_run+0xba/0x100 [11057.643263] exit_to_usermode_loop+0xe4/0xf0 [11057.643286] do_syscall_64+0x27e/0x2c0 [11057.643314] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [11057.643339] [11057.643359] read to 0xffff8881f24471a0 of 8 bytes by task 44667 on cpu 3: [11057.643774] i915_gem_mmap+0x295/0x670 [i915] [11057.643802] mmap_region+0x62b/0xac0 [11057.643825] do_mmap+0x414/0x6b0 [11057.643848] vm_mmap_pgoff+0xa9/0xf0 [11057.643875] ksys_mmap_pgoff+0x1ac/0x2f0 [11057.643900] do_syscall_64+0x6e/0x2c0 [11057.643924] entry_SYSCALL_64_after_hwframe+0x44/0xa9 Signed-off-by:
-
Chris Wilson authored
Record the initial active element we use when building the next ELSP submission, so that we can compare against it latter to see if there's no change. Fixes: 44d0a9c0 ("drm/i915/execlists: Skip redundant resubmission") Signed-off-by:
-
Chris Wilson authored
Avoid angering kcsan by serialising the read of the pm_events with the write in rps_disable_interrupts. [ 6268.713419] BUG: KCSAN: data-race in intel_rps_park [i915] / rps_work [i915] [ 6268.713437] [ 6268.713449] write to 0xffff8881eda8efac of 4 bytes by task 1127 on cpu 3: [ 6268.713680] intel_rps_park+0x136/0x260 [i915] [ 6268.713905] __gt_park+0x61/0xa0 [i915] [ 6268.714128] ____intel_wakeref_put_last+0x42/0x90 [i915] [ 6268.714352] __intel_wakeref_put_work+0xd3/0xf0 [i915] [ 6268.714369] process_one_work+0x3b1/0x690 [ 6268.714384] worker_thread+0x80/0x670 [ 6268.714398] kthread+0x19a/0x1e0 [ 6268.714412] ret_from_fork+0x1f/0x30 [ 6268.714423] [ 6268.714435] read to 0xffff8881eda8efac of 4 bytes by task 950 on cpu 2: [ 6268.714664] rps_work+0xc2/0x680 [i915] [ 6268.714679] process_one_work+0x3b1/0x690 [ 6268.714693] worker_thread+0x80/0x670 [ 6268.714707] kthread+0x19a/0x1e0 [ 6268.714720] ret_from_fork+0x1f/0x30 v2: Mark all reads and writes of rpm->pm_events. The flow of enabling/disabling rps is stronly ordered, so the writes and interrupt generation are also strongly ordered -- just this may not be visible to the compiler, so provide annotations. Signed-off-by:
-
Chris Wilson authored
Extend i915_request_await_active() to be able to asynchronously wait on all the tracked timelines simultaneously. Signed-off-by:
-
Takashi Iwai authored
Since snprintf() returns the would-be-output size instead of the actual output size, the succeeding calls may go beyond the given buffer limit. Fix it by replacing with scnprintf(). Signed-off-by:
Takashi Iwai <tiwai@suse.de> Reviewed-by:
-
Wambui Karuga authored
Convert various instances of the printk based drm logging macros to the struct drm_device based logging macros in i915/display/intel_overlay.c. This transformation was achieved using the following coccinelle script: @@ identifier fn, T; @@ fn(...,struct drm_i915_private *T,...) { <+... ( -DRM_INFO( +drm_info(&T->drm, ...) | -DRM_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_DRIVER( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_KMS( +drm_dbg_kms(&T->drm, ...) | -DRM_DEBUG_ATOMIC( +drm_dbg_atomic(&T->drm, ...) ) ...+> } @@ identifier fn, T; @@ fn(...) { ... struct drm_i915_private *T = ...; <+... ( -DRM_INFO( +drm_info(&T->drm, ...) | -DRM_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_KMS( +drm_dbg_kms(&T->drm, ...) | -DRM_DEBUG_DRIVER( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_ATOMIC( +drm_dbg_atomic(&T->drm, ...) ) ...+> } Note that this converts DRM_DEBUG to drm_dbg(). Checkpatch warnings were addressed manually. References: https://lists.freedesktop.org/archives/dri-devel/2020-January/253381.htmlSigned-off-by:Wambui Karuga <wambui.karugax@gmail.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/ca3c14de13e308419caf33eb4bbf274f5387f1e0.1583766715.git.jani.nikula@intel.com
-
Wambui Karuga authored
Converts various instances of the printk based drm logging macros to the struct drm_device based logging macros in i915/display/intel_lvds.c. This transformation was done by the following coccinelle script that matches based on the existence of a drm_i915_private device: @@ identifier fn, T; @@ fn(...,struct drm_i915_private *T,...) { <+... ( -DRM_INFO( +drm_info(&T->drm, ...) | -DRM_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_DRIVER( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_KMS( +drm_dbg_kms(&T->drm, ...) | -DRM_DEBUG_ATOMIC( +drm_dbg_atomic(&T->drm, ...) ) ...+> } @@ identifier fn, T; @@ fn(...) { ... struct drm_i915_private *T = ...; <+... ( -DRM_INFO( +drm_info(&T->drm, ...) | -DRM_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_KMS( +drm_dbg_kms(&T->drm, ...) | -DRM_DEBUG_DRIVER( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_ATOMIC( +drm_dbg_atomic(&T->drm, ...) ) ...+> } New checkpatch warnings were fixed manually. Signed-off-by: -
Wambui Karuga authored
Convert various uses of the printk based drm logging macros to the struct drm_device based logging macros in i915/display/intel_lpe_audio.c. Note that this converts DRM_DEBUG to drm_dbg(). References: https://lists.freedesktop.org/archives/dri-devel/2020-January/253381.htmlSigned-off-by:
-
Wambui Karuga authored
Converts various instances of the printk based drm logging macros to the struct drm_device based logging macros in i915/display/intel_hotplug.c. In some cases, this involves extracting the drm_i915_private pointer from the drm_device struct to be used in the logging macros. Signed-off-by:
-
Wambui Karuga authored
Conversion instances of printk based drm logging macros to use the struct drm_device based logging macros in i915/display/intel_gmbus.c. This was done using the following coccinelle semantic patch that transforms based on the existence of an existing drm_i915_private device: @@ identifier fn, T; @@ fn(...,struct drm_i915_private *T,...) { <+... ( -DRM_INFO( +drm_info(&T->drm, ...) | -DRM_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_DRIVER( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_KMS( +drm_dbg_kms(&T->drm, ...) | -DRM_DEBUG_ATOMIC( +drm_dbg_atomic(&T->drm, ...) ) ...+> } @@ identifier fn, T; @@ fn(...) { ... struct drm_i915_private *T = ...; <+... ( -DRM_INFO( +drm_info(&T->drm, ...) | -DRM_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_KMS( +drm_dbg_kms(&T->drm, ...) | -DRM_DEBUG_DRIVER( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_ATOMIC( +drm_dbg_atomic(&T->drm, ...) ) ...+> } New checkpatch warnings were addressed manually. Signed-off-by: -
Wambui Karuga authored
Convert various instances of the printk based drm logging macros to the struct drm_device based logging macros in i915/display/intel_fifo_underrun.c. This was done using the following coccinelle script: @@ identifier fn, T; @@ fn(...,struct drm_i915_private *T,...) { <+... ( -DRM_INFO( +drm_info(&T->drm, ...) | -DRM_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_DRIVER( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_KMS( +drm_dbg_kms(&T->drm, ...) | -DRM_DEBUG_ATOMIC( +drm_dbg_atomic(&T->drm, ...) ) ...+> } @@ identifier fn, T; @@ fn(...) { ... struct drm_i915_private *T = ...; <+... ( -DRM_INFO( +drm_info(&T->drm, ...) | -DRM_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_KMS( +drm_dbg_kms(&T->drm, ...) | -DRM_DEBUG_DRIVER( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_ATOMIC( +drm_dbg_atomic(&T->drm, ...) ) ...+> } New checkpatch warnings were addressed manually. Signed-off-by: -
Wambui Karuga authored
This converts uses of the printk based drm logging macros to the struct drm_device logging macros in i915/display/intel_dsb.c. This was done using the following coccinelle script: @@ identifier fn, T; @@ fn(...,struct drm_i915_private *T,...) { <+... ( -DRM_INFO( +drm_info(&T->drm, ...) | -DRM_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_DRIVER( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_KMS( +drm_dbg_kms(&T->drm, ...) | -DRM_DEBUG_ATOMIC( +drm_dbg_atomic(&T->drm, ...) ) ...+> } @@ identifier fn, T; @@ fn(...) { ... struct drm_i915_private *T = ...; <+... ( -DRM_INFO( +drm_info(&T->drm, ...) | -DRM_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_KMS( +drm_dbg_kms(&T->drm, ...) | -DRM_DEBUG_DRIVER( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_ATOMIC( +drm_dbg_atomic(&T->drm, ...) ) ...+> } Checkpatch warnings were fixed manually. Signed-off-by: -
Tvrtko Ursulin authored
The two files have been duplicated under the gt/ subdir and since there are not apparent users looking for them at the old location lets simply remove them and duplicated code. Signed-off-by:
Andi Shyti <andi.shyti@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200310164733.26487-1-tvrtko.ursulin@linux.intel.com
-
- 10 Mar, 2020 3 commits
-
-
Chris Wilson authored
The virtual engine passes tokens back and forth to its backing physical engines. [ 57.372993] BUG: KCSAN: data-race in execlists_dequeue [i915] / virtual_submission_tasklet [i915] [ 57.373012] [ 57.373023] write to 0xffff8881f47324c0 of 4 bytes by interrupt on cpu 2: [ 57.373241] execlists_dequeue+0x6fa/0x2150 [i915] [ 57.373458] __execlists_submission_tasklet+0x48/0x60 [i915] [ 57.373677] execlists_submission_tasklet+0xd3/0x170 [i915] [ 57.373694] tasklet_action_common.isra.0+0x42/0xa0 [ 57.373709] __do_softirq+0xd7/0x2cd [ 57.373723] irq_exit+0xbe/0xe0 [ 57.373735] do_IRQ+0x51/0x100 [ 57.373748] ret_from_intr+0x0/0x1c [ 57.373963] engine_retire+0x89/0xe0 [i915] [ 57.373977] process_one_work+0x3b1/0x690 [ 57.373990] worker_thread+0x80/0x670 [ 57.374004] kthread+0x19a/0x1e0 [ 57.374017] ret_from_fork+0x1f/0x30 [ 57.374027] [ 57.374038] read to 0xffff8881f47324c0 of 4 bytes by interrupt on cpu 3: [ 57.374256] virtual_submission_tasklet+0x27/0x5a0 [i915] [ 57.374273] tasklet_action_common.isra.0+0x42/0xa0 [ 57.374288] __do_softirq+0xd7/0x2cd [ 57.374302] run_ksoftirqd+0x15/0x20 [ 57.374315] smpboot_thread_fn+0x1ab/0x300 [ 57.374329] kthread+0x19a/0x1e0 [ 57.374342] ret_from_fork+0x1f/0x30 Signed-off-by:
-
Chris Wilson authored
As a virtual engine may change the rq->engine to point to the active request in flight, we need to warn the compiler that an active request's engine is volatile. [ 95.017686] write (marked) to 0xffff8881e8386b10 of 8 bytes by interrupt on cpu 2: [ 95.018123] execlists_dequeue+0x762/0x2150 [i915] [ 95.018539] __execlists_submission_tasklet+0x48/0x60 [i915] [ 95.018955] execlists_submission_tasklet+0xd3/0x170 [i915] [ 95.018986] tasklet_action_common.isra.0+0x42/0xa0 [ 95.019016] __do_softirq+0xd7/0x2cd [ 95.019043] irq_exit+0xbe/0xe0 [ 95.019068] irq_work_interrupt+0xf/0x20 [ 95.019491] i915_request_retire+0x2c5/0x670 [i915] [ 95.019937] retire_requests+0xa1/0xf0 [i915] [ 95.020348] engine_retire+0xa1/0xe0 [i915] [ 95.020376] process_one_work+0x3b1/0x690 [ 95.020403] worker_thread+0x80/0x670 [ 95.020429] kthread+0x19a/0x1e0 [ 95.020454] ret_from_fork+0x1f/0x30 [ 95.020476] [ 95.020498] read to 0xffff8881e8386b10 of 8 bytes by task 8909 on cpu 3: [ 95.020918] __i915_request_commit+0x177/0x220 [i915] [ 95.021329] i915_gem_do_execbuffer+0x38c4/0x4e50 [i915] [ 95.021750] i915_gem_execbuffer2_ioctl+0x2c3/0x580 [i915] [ 95.021784] drm_ioctl_kernel+0xe4/0x120 [ 95.021809] drm_ioctl+0x297/0x4c7 [ 95.021832] ksys_ioctl+0x89/0xb0 [ 95.021865] __x64_sys_ioctl+0x42/0x60 [ 95.021901] do_syscall_64+0x6e/0x2c0 [ 95.021927] entry_SYSCALL_64_after_hwframe+0x44/0xa9 Signed-off-by:
-
Chris Wilson authored
When being used across multiple real engines inside a virtual engine, the intel_context.inflight is updated atomically, and so we must annotate the racy read from outside the owning context. [11142.482846] BUG: KCSAN: data-race in __execlists_submission_tasklet [i915] / __execlists_submission_tasklet [i915] [11142.482867] [11142.482878] write (marked) to 0xffff8881f257b5e0 of 8 bytes by interrupt on cpu 2: [11142.483107] __execlists_submission_tasklet+0x1d33/0x2120 [i915] [11142.483336] execlists_submission_tasklet+0xd3/0x170 [i915] [11142.483355] tasklet_action_common.isra.0+0x42/0xa0 [11142.483371] __do_softirq+0xd7/0x2cd [11142.483384] irq_exit+0xbe/0xe0 [11142.483401] do_IRQ+0x51/0x100 [11142.483424] ret_from_intr+0x0/0x1c [11142.483446] do_idle+0x133/0x1f0 [11142.483465] cpu_startup_entry+0x14/0x16 [11142.483483] start_secondary+0x120/0x180 [11142.483498] secondary_startup_64+0xa4/0xb0 [11142.483512] [11142.483528] read to 0xffff8881f257b5e0 of 8 bytes by interrupt on cpu 1: [11142.483755] __execlists_submission_tasklet+0x14e/0x2120 [i915] [11142.483981] execlists_submission_tasklet+0xd3/0x170 [i915] [11142.483999] tasklet_action_common.isra.0+0x42/0xa0 [11142.484014] __do_softirq+0xd7/0x2cd [11142.484028] do_softirq_own_stack+0x2a/0x40 [11142.484046] do_softirq.part.0+0x26/0x30 [11142.484071] __local_bh_enable_ip+0x46/0x50 [11142.484299] i915_gem_do_execbuffer+0x39c1/0x4e50 [i915] [11142.484528] i915_gem_execbuffer2_ioctl+0x2c3/0x580 [i915] [11142.484546] drm_ioctl_kernel+0xe4/0x120 [11142.484559] drm_ioctl+0x297/0x4c7 [11142.484572] ksys_ioctl+0x89/0xb0 [11142.484586] __x64_sys_ioctl+0x42/0x60 [11142.484610] do_syscall_64+0x6e/0x2c0 [11142.484627] entry_SYSCALL_64_after_hwframe+0x44/0xa9 Signed-off-by:
-
