- 14 Dec, 2021 3 commits
-
-
Chris Wilson authored
This extends the previous sanitychecking of device memory to read/write all the memory on the device during the device probe, ala memtest86, as an optional module parameter: i915.memtest=1. This is not expected to be fast, but a reasonably thorough verfification that the device memory is accessible and doesn't return bit errors. v2: Rebased. Suggested-by:
Matthew Auld <matthew.auld@intel.com> Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Matthew Auld <matthew.auld@intel.com> Signed-off-by:
Ramalingam C <ramalingam.c@intel.com> Reviewed-by:
Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211208153404.27546-4-ramalingam.c@intel.com
-
Chris Wilson authored
As we setup the memory regions for the device, give each a quick test to verify that we can read and write to the full iomem range. This ensures that our physical addressing for the device's memory is correct, and some reassurance that the memory is functional. v2: wrapper for memtest [Chris] v3: Removed the unused ptr i915 [Chris] v4: used the %pa for the resource_size_t. Signed-off-by:
-
Chris Wilson authored
Remove the portion of stolen memory reserved for private use from driver access. Signed-off-by:
-
- 13 Dec, 2021 6 commits
-
-
Thomas Hellström authored
When we recently converted the capture code to use vma snapshots, we forgot to free the struct i915_capture_list list items after use. Fix that by bringing back a kfree. Fixes: ff20afc4 ("drm/i915: Update error capture code to avoid using the current vma state") Cc: Ramalingam C <ramalingam.c@intel.com> Signed-off-by:
Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by:
-
Daniele Ceraolo Spurio authored
Some of the newer HW will use bigger RSA keys to authenticate the GuC binary. On those platforms the HW will read the key from memory instead of the RSA registers, so we need to copy it in a dedicated vma, like we do for the HuC. The address of the key is provided to the HW via the first RSA register. v2: clarify that the RSA behavior is hardcoded in the bootrom (Matt) Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by:
Matthew Brost <matthew.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211211000756.1698923-4-daniele.ceraolospurio@intel.com
-
Michal Wajdeczko authored
Future GuC/HuC firmwares might be signed with different key sizes. Don't assume that it must be always 2048 bits long. Signed-off-by:
Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by:
-
Daniele Ceraolo Spurio authored
The FAILURE state of uc_fw currently implies that the fw is loadable (i.e init completed), so we can't use it for init failures and instead need a dedicated error code. Note that this currently does not cause any issues because if we fail to init any of the firmwares we abort the load, but better be accurate anyway in case things change in the future. Signed-off-by:
-
Thomas Hellström authored
When updating the error capture code and introducing vma snapshots, we introduced code to hold the vma in memory while capturing it, calling i915_active_acquire_if_busy(). Now that function isn't relevant for perma-pinned vmas and caused important vmas to be dropped from the coredump. Like for example the GuC log. Fix this by instead requiring those vmas to be pinned while capturing. Tested by running the initial subtests of the gem_exec_capture igt test with GuC submission enabled and verifying that a GuC log blob appears in the output. Fixes: ff20afc4 ("drm/i915: Update error capture code to avoid using the current vma state") Cc: Ramalingam C <ramalingam.c@intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reported-by:
John Harrison <John.C.Harrison@Intel.com> Signed-off-by:
-
Sebastian Andrzej Siewior authored
This is a revert of commits d6773926 ("drm/i915/gt: Mark up the nested engine-pm timeline lock as irqsafe") 6c69a454 ("drm/i915/gt: Mark context->active_count as protected by timeline->mutex") 6dcb85a0 ("drm/i915: Hold irq-off for the entire fake lock period") The existing code leads to a different behaviour depending on whether lockdep is enabled or not. Any following lock that is acquired without disabling interrupts (but needs to) will not be noticed by lockdep. This it not just a lockdep annotation but is used but an actual mutex_t that is properly used as a lock but in case of __timeline_mark_lock() lockdep is only told that it is acquired but no lock has been acquired. It appears that its purpose is just satisfy the lockdep_assert_held() check in intel_context_mark_active(). The other problem with disabling interrupts is that on PREEMPT_RT interrupts are also disabled which leads to problems for instance later during memory allocation. Add a CONTEXT_IS_PARKING bit to intel_engine_cs and set_bit/clear_bit it instead of mutex_acquire/mutex_release. Use test_bit in the two identified spots which relied on the lockdep annotation. Cc: Peter Zijlstra <peterz@infradead.org> Signed-off-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> Acked-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by:
-
- 11 Dec, 2021 2 commits
-
-
John Harrison authored
If the GuC has failed to load for any reason and then the user pokes the debugfs GuC log interface, a BUG and/or null pointer deref can occur. Don't let that happen. Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211210044022.1842938-5-John.C.Harrison@Intel.com
-
John Harrison authored
It is possible for platforms to require GuC but not HuC firmware. Also, the firmware versions for GuC and HuC advance independently. So split the macros up to allow the lists to be maintained separately. Signed-off-by:
-
- 09 Dec, 2021 6 commits
-
-
Umesh Nerlige Ramappa authored
GuC PMU busyness gets gt wakeref if awake, but fails to release the wakeref if a reset is in progress. Release the wakeref if it was acquried successfully. v2: Simplify the fix (Ashutosh) Fixes: 2a67b18e ("drm/i915/pmu: Fix synchronization of PMU callback with reset") Signed-off-by:
Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Reviewed-by:
Ashutosh Dixit <ashutosh.dixit@intel.com> Signed-off-by:
-
Umesh Nerlige Ramappa authored
live_engine_busy_stats waits for busyness to start ticking before sampling busyness for the test sample duration. The wait accesses an MMIO register and the uncore call to read it takes up to 3 ms in the worst case. This can result in the wait timing out since the MMIO read itself consumes up the timeout of 500us. Increase the timeout to a larger value of 10ms to account for the MMIO read time. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4536 Fixes: 77cdd054 ("drm/i915/pmu: Connect engine busyness stats from GuC to pmu") Signed-off-by:
-
Matthew Auld authored
If the device needs 64K minimum GTT pages for device local-memory, like on XEHPSDV, then we need to fail the allocation if we can't meet it, instead of falling back to 4K pages, otherwise we can't safely support the insertion of device local-memory pages for this vm, since the HW expects the correct physical alignment and size for every PTE, if we mark the page-table as 64K GTT mode. v2: s/userpsace/userspace [Thomas] Signed-off-by:
-
Matthew Auld authored
On some platforms the hw has dropped support for 4K GTT pages when dealing with LMEM, and due to the design of 64K GTT pages in the hw, we can only mark the *entire* page-table as operating in 64K GTT mode, since the enable bit is still on the pde, and not the pte. And since we we still need to allow 4K GTT pages for SMEM objects, we can't have a "normal" 4K page-table with scratch pointing to LMEM, since that's undefined from the hw pov. The simplest solution is to just move the 64K scratch page to SMEM on such platforms and call it a day, since that should work for all configurations. Signed-off-by:
-
Matthew Auld authored
Conditionally allocate LMEM with 64K granularity, since 4K page support for LMEM will be dropped on some platforms when using the PPGTT. v2: updated commit msg [Thomas] Signed-off-by:
Stuart Summers <stuart.summers@intel.com> Signed-off-by:
-
Stuart Summers authored
Add a new platform flag, has_64k_pages, to mark the requirement of 64K GTT page sizes or larger for device local memory access. Also implies that we require or at least support the compact PT layout for the ppGTT when using 64K GTT pages. v2: More explanation for the flag [Thomas] Signed-off-by:
-
- 08 Dec, 2021 5 commits
-
-
Tejas Upadhyay authored
We need a way to reset engines by their reset domains. This change sets up way to fetch reset domains of each engine globally. Changes since V1: - Use static reset domain array - Ville and Tvrtko - Use BUG_ON at appropriate place - Tvrtko Signed-off-by:
Tejas Upadhyay <tejaskumarx.surendrakumar.upadhyay@intel.com> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Matthew Auld authored
Ensure we account for any object rounding due to min_page_size restrictions. Signed-off-by:
-
Matthew Auld authored
No need to insert PTEs for the PTE window itself, also foreach expects a length not an end offset, which could be gigantic here with a second engine. Signed-off-by:
-
Matthew Auld authored
Ensure we add the engine base only after we calculate the qword offset into the PTE window. Signed-off-by:
-
Matthew Auld authored
The scratch page might not be allocated in LMEM(like on DG2), so instead of using that as the deciding factor for where the paging structures live, let's just query the pt before mapping it. Signed-off-by:
-
- 07 Dec, 2021 2 commits
-
-
Bruce Chang authored
Follow up on below commit, to increase the timeout further on new platforms, to accomodate the additional time required for the completion of guc submissions for numerous requests created in loop. commit 5e076529 Author: Matthew Brost <matthew.brost@intel.com> Date: Mon Jul 26 20:17:03 2021 -0700 drm/i915/selftests: Increase timeout in i915_gem_contexts selftests Signed-off-by:
Bruce Chang <yu.bruce.chang@intel.com> Reviewed-by:
-
Michael Cheng authored
Certain functions within i915 uses macros that are defined for specific architectures by the mmu, such as _PAGE_RW and _PAGE_PRESENT (Some architectures don't even have these macros defined, like ARM64). Instead of re-using bits defined for the CPU, we should use bits defined for i915. This patch introduces two new 64 bit macros, GEN8_PAGE_PRESENT and GEN8_PAGE_RW, to check for bits 0 and 1 and, to replace all occurrences of _PAGE_RW and _PAGE_PRESENT within i915. v2(Michael Cheng): Use GEN8_ instead of I915_ Signed-off-by:
Michael Cheng <michael.cheng@intel.com> Reviewed-by:
-
- 03 Dec, 2021 4 commits
-
-
Dan Carpenter authored
Originally "out_fence" was set using out_fence = sync_file_create() but which returns NULL, but now it is set with out_fence = eb_requests_create() which returns error pointers. The error path needs to be modified to avoid an Oops in the "goto err_request;" path. Fixes: 544460c3 ("drm/i915: Multi-BB execbuf") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Raviteja Goud Talla authored
Bspec page says "Reset: BUS", Accordingly moving w/a's: Wa_1407352427,Wa_1406680159 to proper function icl_gt_workarounds_init() Which will resolve guc enabling error v2: - Previous patch rev2 was created by email client which caused the Build failure, This v2 is to resolve the previous broken series Reviewed-by:Raviteja Goud Talla <ravitejax.goud.talla@intel.com> Signed-off-by:
-
Ramalingam C authored
Invalidate IC cache through pipe control command as part of the ctx restore flow through indirect ctx pointer. v2: - Move pipe control from xcs indirect context to the rcs indirect context. We'll eventually need this on the CCS engines too, but support for those hasn't landed yet. Cc: Chris Wilson <chris.p.wilson@intel.com> Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> Reviewed-by:
Clint Taylor <Clinton.A.Taylor@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211116174818.2128062-5-matthew.d.roper@intel.com
-
Matt Roper authored
Coarse power gating for render should not be enabled on some DG2 steppings. Bspec: 52698 Signed-off-by:
-
- 01 Dec, 2021 7 commits
-
-
José Roberto de Souza authored
Those two workarounds needs to be implemented in UMD, KMD only needs to whitelist the registers, so here only adding the workaround number to facilitate future workaroud table checks. Signed-off-by:
José Roberto de Souza <jose.souza@intel.com> Reviewed-by:
Matt Atwood <matthew.s.atwood@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211119140931.32791-2-jose.souza@intel.com
-
José Roberto de Souza authored
This workarounds are causing hangs, because I missed the fact that it needs to be enabled for all cases and disabled when doing a resolve pass. So KMD only needs to whitelist it and UMD will be the one setting it on per case. This reverts commit 28ec02c9. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4145Signed-off-by:
-
Thomas Hellström authored
With asynchronous migrations, the vma state may be several migrations ahead of the state that matches the request we're capturing. Address that by introducing an i915_vma_snapshot structure that can be used to snapshot relevant state at request submission. In order to make sure we access the correct memory, the snapshots take references on relevant sg-tables and memory regions. Also move the capture list allocation out of the fence signaling critical path and use the CONFIG_DRM_I915_CAPTURE_ERROR define to avoid compiling in members and functions used for error capture when they're not used. Finally, Introduce lockdep annotation. v4: - Break out the capture allocation mode change to a separate patch. v5: - Fix compilation error in the !CONFIG_DRM_I915_CAPTURE_ERROR case (kernel test robot) v6: - Use #if IS_ENABLED() instead of #ifdef to match driver style. - Move yet another change of allocation mode to the separate patch. - Commit message rework due to patch reordering. v7: - Adjust for removal of region refcounting. Signed-off-by:
-
Zhou Qingyang authored
In igt_request_rewind(), mock_context(i915, "A") is assigned to ctx[0] and used in i915_gem_context_get_engine(). There is a dereference of ctx[0] in i915_gem_context_get_engine(), which could lead to a NULL pointer dereference on failure of mock_context(i915, "A") . So as mock_context(i915, "B"). Although this bug is not serious for it belongs to testing code, it is better to be fixed to avoid unexpected failure in testing. Fix this bugs by adding checks about ctx[0] and ctx[1]. This bug was found by a static analyzer. The analysis employs differential checking to identify inconsistent security operations (e.g., checks or kfrees) between two code paths and confirms that the inconsistent operations are not recovered in the current function or the callers, so they constitute bugs. Note that, as a bug found by static analysis, it can be a false positive or hard to trigger. Multiple researchers have cross-reviewed the bug. Builds with CONFIG_DRM_I915_SELFTEST=y show no new warnings, and our static analyzer no longer warns about this code. References: 591c0fb8 ("drm/i915: Exercise request cancellation using a mock selftest") [tursulin: Replaced fixes with references to avoid.] Signed-off-by:
Zhou Qingyang <zhou1615@umn.edu> Reviewed-by:
-
Tvrtko Ursulin authored
With both integrated and discrete Intel GPUs in a system, the current global check of intel_iommu_gfx_mapped, as done from intel_vtd_active() may not be completely accurate. In this patch we add i915 parameter to intel_vtd_active() in order to prepare it for multiple GPUs and we also change the check away from Intel specific intel_iommu_gfx_mapped (global exported by the Intel IOMMU driver) to probing the presence of IOMMU on a specific device using device_iommu_mapped(). This will return true both for IOMMU pass-through and address translation modes which matches the current behaviour. If in the future we wanted to distinguish between these two modes we could either use iommu_get_domain_for_dev() and check for __IOMMU_DOMAIN_PAGING bit indicating address translation, or ask for a new API to be exported from the IOMMU core code. v2: * Check for dmar translation specifically, not just iommu domain. (Baolu) v3: * Go back to plain "any domain" check for now, rewrite commit message. v4: * Use device_iommu_mapped. (Robin, Baolu) Signed-off-by:
Robin Murphy <robin.murphy@arm.com> Reviewed-by:
Lu Baolu <baolu.lu@linux.intel.com> Reviewed-by:
-
Matthew Brost authored
Rather than stealing bits from i915_sw_fence function pointer use separate fields for function pointer and flags. If using two different fields, the 4 byte alignment for the i915_sw_fence function pointer can also be dropped. v2: (CI) - Set new function field rather than flags in __i915_sw_fence_init v3: (Tvrtko) - Remove BUG_ON(!fence->flags) in reinit as that will now blow up - Only define fence->flags if CONFIG_DRM_I915_SW_FENCE_CHECK_DAG is defined v4: - Rebase, resend for CI Signed-off-by:Jani Nikula <jani.nikula@intel.com> Reviewed-by:
Alan Previn <alan.previn.teres.alexis@intel.com> Signed-off-by:
-
Umesh Nerlige Ramappa authored
Since the PMU callback runs in irq context, it synchronizes with gt reset using the reset count. We could run into a case where the PMU callback could read the reset count before it is updated. This has a potential of corrupting the busyness stats. In addition to the reset count, check if the reset bit is set before capturing busyness. In addition save the previous stats only if you intend to update them. v2: - The 2 reset counts captured in the PMU callback can end up being the same if they were captured right after the count is incremented in the reset flow. This can lead to a bad busyness state. Ensure that reset is not in progress when the initial reset count is captured. Signed-off-by:
-
- 30 Nov, 2021 1 commit
-
-
Thomas Hellström authored
If a dma_fence_array is reported signaled by a call to dma_fence_is_signaled(), it may leak the PENDING_ERROR status. Fix this by clearing the PENDING_ERROR status if we return true in dma_fence_array_signaled(). v2: - Update Cc list, and add R-b. Fixes: 1f70b8b8 ("dma-fence: Propagate errors to dma-fence-array container") Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Sumit Semwal <sumit.semwal@linaro.org> Cc: Gustavo Padovan <gustavo@padovan.org> Cc: Christian König <christian.koenig@amd.com> Cc: "Christian König" <christian.koenig@amd.com> Cc: linux-media@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: linaro-mm-sig@lists.linaro.org Cc: <stable@vger.kernel.org> # v5.4+ Signed-off-by:
Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211129152727.448908-1-thomas.hellstrom@linux.intel.com
-
- 26 Nov, 2021 3 commits
-
-
Matthew Auld authored
vfs_kernel_mount() modifies the passed in mount options, leaving us with "huge", instead of "huge=within_size". Normally this shouldn't matter with the usual module load/unload flow, however with the core_hotunplug IGT we are hitting the following, when re-probing the memory regions: i915 0000:00:02.0: [drm] Transparent Hugepage mode 'huge' tmpfs: Bad value for 'huge' [drm] Unable to create a private tmpfs mount, hugepage support will be disabled(-22). References: https://gitlab.freedesktop.org/drm/intel/-/issues/4651Signed-off-by:
-
Thomas Hellström authored
The capture code is typically run entirely in the fence signalling critical path. We're about to add lockdep annotation in an upcoming patch which reveals a lockdep splat similar to the below one. Fix the associated potential deadlocks using __GFP_KSWAPD_RECLAIM (which is the same as GFP_WAIT, but open-coded for clarity) rather than GFP_KERNEL for memory allocation in the capture path. This has the potential drawback that capture might fail in situations with memory pressure. [ 234.842048] WARNING: possible circular locking dependency detected [ 234.842050] 5.15.0-rc7+ #20 Tainted: G U W [ 234.842052] ------------------------------------------------------ [ 234.842054] gem_exec_captur/1180 is trying to acquire lock: [ 234.842056] ffffffffa3e51c00 (fs_reclaim){+.+.}-{0:0}, at: __kmalloc+0x4d/0x330 [ 234.842063] but task is already holding lock: [ 234.842064] ffffffffa3f57620 (dma_fence_map){++++}-{0:0}, at: i915_vma_snapshot_resource_pin+0x27/0x30 [i915] [ 234.842138] which lock already depends on the new lock. [ 234.842140] the existing dependency chain (in reverse order) is: [ 234.842142] -> #2 (dma_fence_map){++++}-{0:0}: [ 234.842145] __dma_fence_might_wait+0x41/0xa0 [ 234.842149] dma_resv_lockdep+0x1dc/0x28f [ 234.842151] do_one_initcall+0x58/0x2d0 [ 234.842154] kernel_init_freeable+0x273/0x2bf [ 234.842157] kernel_init+0x16/0x120 [ 234.842160] ret_from_fork+0x1f/0x30 [ 234.842163] -> #1 (mmu_notifier_invalidate_range_start){+.+.}-{0:0}: [ 234.842166] fs_reclaim_acquire+0x6d/0xd0 [ 234.842168] __kmalloc_node+0x51/0x3a0 [ 234.842171] alloc_cpumask_var_node+0x1b/0x30 [ 234.842174] native_smp_prepare_cpus+0xc7/0x292 [ 234.842177] kernel_init_freeable+0x160/0x2bf [ 234.842179] kernel_init+0x16/0x120 [ 234.842181] ret_from_fork+0x1f/0x30 [ 234.842184] -> #0 (fs_reclaim){+.+.}-{0:0}: [ 234.842186] __lock_acquire+0x1161/0x1dc0 [ 234.842189] lock_acquire+0xb5/0x2b0 [ 234.842192] fs_reclaim_acquire+0xa1/0xd0 [ 234.842193] __kmalloc+0x4d/0x330 [ 234.842196] i915_vma_coredump_create+0x78/0x5b0 [i915] [ 234.842253] intel_engine_coredump_add_vma+0x36/0xe0 [i915] [ 234.842307] __i915_gpu_coredump+0x290/0x5e0 [i915] [ 234.842365] i915_capture_error_state+0x57/0xa0 [i915] [ 234.842415] intel_gt_handle_error+0x348/0x3e0 [i915] [ 234.842462] intel_gt_debugfs_reset_store+0x3c/0x90 [i915] [ 234.842504] simple_attr_write+0xc1/0xe0 [ 234.842507] full_proxy_write+0x53/0x80 [ 234.842509] vfs_write+0xbc/0x350 [ 234.842513] ksys_write+0x58/0xd0 [ 234.842514] do_syscall_64+0x38/0x90 [ 234.842516] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 234.842519] other info that might help us debug this: [ 234.842521] Chain exists of: fs_reclaim --> mmu_notifier_invalidate_range_start --> dma_fence_map [ 234.842526] Possible unsafe locking scenario: [ 234.842528] CPU0 CPU1 [ 234.842529] ---- ---- [ 234.842531] lock(dma_fence_map); [ 234.842532] lock(mmu_notifier_invalidate_range_start); [ 234.842535] lock(dma_fence_map); [ 234.842537] lock(fs_reclaim); [ 234.842539] *** DEADLOCK *** [ 234.842540] 4 locks held by gem_exec_captur/1180: [ 234.842543] #0: ffff9007812d9460 (sb_writers#17){.+.+}-{0:0}, at: ksys_write+0x58/0xd0 [ 234.842547] #1: ffff900781d9ecb8 (&attr->mutex){+.+.}-{3:3}, at: simple_attr_write+0x3a/0xe0 [ 234.842552] #2: ffffffffc11913a8 (capture_mutex){+.+.}-{3:3}, at: i915_capture_error_state+0x1a/0xa0 [i915] [ 234.842602] #3: ffffffffa3f57620 (dma_fence_map){++++}-{0:0}, at: i915_vma_snapshot_resource_pin+0x27/0x30 [i915] [ 234.842656] stack backtrace: [ 234.842658] CPU: 0 PID: 1180 Comm: gem_exec_captur Tainted: G U W 5.15.0-rc7+ #20 [ 234.842661] Hardware name: ASUS System Product Name/PRIME B560M-A AC, BIOS 0403 01/26/2021 [ 234.842664] Call Trace: [ 234.842666] dump_stack_lvl+0x57/0x72 [ 234.842669] check_noncircular+0xde/0x100 [ 234.842672] ? __lock_acquire+0x3bf/0x1dc0 [ 234.842675] __lock_acquire+0x1161/0x1dc0 [ 234.842678] lock_acquire+0xb5/0x2b0 [ 234.842680] ? __kmalloc+0x4d/0x330 [ 234.842683] ? finish_task_switch.isra.0+0xf2/0x360 [ 234.842686] ? i915_vma_coredump_create+0x78/0x5b0 [i915] [ 234.842734] fs_reclaim_acquire+0xa1/0xd0 [ 234.842737] ? __kmalloc+0x4d/0x330 [ 234.842739] __kmalloc+0x4d/0x330 [ 234.842742] i915_vma_coredump_create+0x78/0x5b0 [i915] [ 234.842793] ? capture_vma+0xbe/0x110 [i915] [ 234.842844] intel_engine_coredump_add_vma+0x36/0xe0 [i915] [ 234.842892] __i915_gpu_coredump+0x290/0x5e0 [i915] [ 234.842939] i915_capture_error_state+0x57/0xa0 [i915] [ 234.842985] intel_gt_handle_error+0x348/0x3e0 [i915] [ 234.843032] ? __mutex_lock+0x81/0x830 [ 234.843035] ? simple_attr_write+0x3a/0xe0 [ 234.843038] ? __lock_acquire+0x3bf/0x1dc0 [ 234.843041] intel_gt_debugfs_reset_store+0x3c/0x90 [i915] [ 234.843083] ? _copy_from_user+0x45/0x80 [ 234.843086] simple_attr_write+0xc1/0xe0 [ 234.843089] full_proxy_write+0x53/0x80 [ 234.843091] vfs_write+0xbc/0x350 [ 234.843094] ksys_write+0x58/0xd0 [ 234.843096] do_syscall_64+0x38/0x90 [ 234.843098] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 234.843101] RIP: 0033:0x7fa467480877 [ 234.843103] Code: 75 05 48 83 c4 58 c3 e8 37 4e ff ff 0f 1f 80 00 00 00 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74 24 [ 234.843108] RSP: 002b:00007ffd14d79b08 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ 234.843112] RAX: ffffffffffffffda RBX: 00007ffd14d79b60 RCX: 00007fa467480877 [ 234.843114] RDX: 0000000000000014 RSI: 00007ffd14d79b60 RDI: 0000000000000007 [ 234.843116] RBP: 0000000000000007 R08: 0000000000000000 R09: 00007ffd14d79ab0 [ 234.843119] R10: ffffffffffffffff R11: 0000000000000246 R12: 0000000000000014 [ 234.843121] R13: 0000000000000000 R14: 00007ffd14d79b60 R15: 0000000000000005 v5: - Use __GFP_KSWAPD_RECLAIM rather than __GFP_NOWAIT for clarity. (Daniel Vetter) v6: - Include an instance in execlists_capture_work(). - Rework the commit message due to patch reordering. Signed-off-by: -
Thomas Hellström authored
The gpu coredump typically takes place in a dma_fence signalling critical path, and hence can't use GFP_KERNEL allocations, as that means we might hit deadlocks under memory pressure. However changing to __GFP_KSWAPD_RECLAIM which will be done in an upcoming patch will instead mean a lower chance of the allocation succeeding. In particular large contigous allocations like the coredump page vector. Remove the page vector in favor of a linked list of single pages. Use the page lru list head as the list link, as the page owner is allowed to do that. Signed-off-by:
-
- 25 Nov, 2021 1 commit
-
-
Maarten Lankhorst authored
The signaled bit is already used for quick testing if a fence is signaled. On top of that, it's a terrible abuse of dma-fence api, and in the common case where the object is already locked by the caller, the trylock will fail. If it were useful, the core dma-api would have exposed the same functionality. The fact that i915 has a dma_resv_utils.c file should be a warning that the functionality either belongs in core, or is not very useful at all. In this case the latter. Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> [mlankhorst: Improve commit message] Acked-by:
-
