- 08 Feb, 2018 3 commits
-
-
Chris Wilson authored
If we remove some hardcoded assumptions about the preempt context having a fixed id, reserved from use by normal user contexts, we may only allocate the i915_gem_context when required. Then the subsequent decisions on using preemption reduce to having the preempt context available. v2: Include an assert that we don't allocate the preempt context twice. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Michal Winiarski <michal.winiarski@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Arkadiusz Hiler <arkadiusz.hiler@intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Acked-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180207210544.26351-3-chris@chris-wilson.co.ukReviewed-by:
Michel Thierry <michel.thierry@intel.com>
-
Chris Wilson authored
Rather than having the high level ioctl interface guess the underlying implementation details, having the implementation declare what capabilities it exports. We define an intel_driver_caps, similar to the intel_device_info, which instead of trying to describe the HW gives details on what the driver itself supports. This is then populated by the engine backend for the new scheduler capability field for use elsewhere. v2: Use caps.scheduler for validating CONTEXT_PARAM_SET_PRIORITY (Mika) One less assumption of engine[RCS] \o/ Signed-off-by:Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by:
Tomasz Lis <tomasz.lis@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180207210544.26351-2-chris@chris-wilson.co.ukReviewed-by:
-
Chris Wilson authored
In the next patch, we may only conditionally allocate the preempt-client if there is a global preempt context and so we need to be prepared in case the preempt-client itself is NULL. v2: Grep for more preempt_client. Signed-off-by:
-
- 07 Feb, 2018 8 commits
-
-
Chris Wilson authored
As we peek inside struct device to query members guarded by CONFIG_PM, so must be the code. Reported-by:
kbuild test robot <fengguang.wu@intel.com> Fixes: 1fe699e3 ("drm/i915/pmu: Fix sleep under atomic in RC6 readout") Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180207160428.17015-1-chris@chris-wilson.co.uk
-
Tvrtko Ursulin authored
We are not allowed to call intel_runtime_pm_get from the PMU counter read callback since the former can sleep, and the latter is running under IRQ context. To workaround this, we record the last known RC6 and while runtime suspended estimate its increase by querying the runtime PM core timestamps. Downside of this approach is that we can temporarily lose a chunk of RC6 time, from the last PMU read-out to runtime suspend entry, but that will eventually catch up, once device comes back online and in the presence of PMU queries. Also, we have to be careful not to overshoot the RC6 estimate, so once resumed after a period of approximation, we only update the counter once it catches up. With the observation that RC6 is increasing while the device is suspended, this should not pose a problem and can only cause slight inaccuracies due clock base differences. v2: Simplify by estimating on top of PM core counters. (Imre) Signed-off-by:
-
Chris Wilson authored
On blb and pnv, we are seeing sporadic i915 0000:00:02.0: Resetting chip after gpu hang [drm:intel_gpu_reset [i915]] rcs0: timed out on STOP_RING [drm:i915_reset [i915]] *ERROR* Failed hw init on reset -5 which notably lack the actual root cause of the error. Ostensibly it should be the init_ring_common() that failed, but it's error paths are covered by DRM_ERROR. Signed-off-by:
-
Chris Wilson authored
If we submit a request and see that the previous request on this timeline was already signaled, we first do not need to add the dependency tracker for that completed request and secondly we know that we there is then a large backlog in retiring requests affecting this timeline. Given that we just submitted more work to the HW, now would be a good time to catch up on those retirements. v2: Try to sum up the compromises involved in flushing the retirement queue after submission. Signed-off-by:
-
Chris Wilson authored
If the last request on the timeline is already complete, we do not need to emit the serialisation barriers. Signed-off-by:
-
Maarten Lankhorst authored
According to bspec, result_lines > 31 is only a maximum for latency level 1 through 7. For level 0 the number of lines is ignored, so always write 0 there to prevent overflowing the 5 bits value. This is required to make NV12 work. Changes since v1: - Rebase on top of GEN11 wm changes. It seems to use res_lines for level 0 limit calculations, but still doesn't appear to program it. Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> #v1 Link: https://patchwork.freedesktop.org/patch/msgid/20180205105841.31634-1-maarten.lankhorst@linux.intel.com
-
Chris Wilson authored
When a request is preempted, it is unsubmitted from the HW queue and removed from the active list of breadcrumbs. In the process, this however triggers the signaler and it may see the clear rbtree with the old, and still valid, seqno, or it may match the cleared seqno with the now zero rq->global_seqno. This confuses the signaler into action and signaling the fence. Fixes: d6a2289d ("drm/i915: Remove the preempted request from the execution queue") Signed-off-by:
-
Joonas Lahtinen authored
Signed-off-by:Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
-
- 06 Feb, 2018 2 commits
-
-
Tvrtko Ursulin authored
Commit 99e48bf9 ("drm/i915: Lock out execlist tasklet while peeking inside for busy-stats") added a tasklet_disable call in busy stats enabling, but we failed to understand that the PMU enable callback runs as an hard IRQ (IPI). Consequence of this is that the PMU enable callback can interrupt the execlists tasklet, and will then deadlock when it calls intel_engine_stats_enable->tasklet_disable. To fix this, I realized it is possible to move the engine stats enablement and disablement to PMU event init and destroy hooks. This allows for much simpler implementation since those hooks run in normal context (can sleep). v2: Extract engine_event_destroy. (Chris Wilson) Signed-off-by:
-
Rafael Antognolli authored
This workaround should prevent a bug that can be hit on a context restore. To avoid the issue, we must emit a PIPE_CONTROL with CS stall (0x7a000004 0x00100000 0x00000000 0x00000000) followed by 12DW's of NOOP(0x0) in the indirect context batch buffer, to ensure the engine is idle prior to programming 3DSTATE_SAMPLE_PATTERN. It's also not clear whether we should add those extra dwords because of the workaround itself, or if that's just padding for the WA BB (and next commands could come right after the PIPE_CONTROL). We keep them for now. References: HSD#1939868 v2: More descriptive changelog and comments. v3: Explain that PIPE_CONTROL is actually 6 dwords, and that we advance 10 more dwords because of that. Signed-off-by:Rafael Antognolli <rafael.antognolli@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Acked-by:
-
- 05 Feb, 2018 14 commits
-
-
Michal Srb authored
The command MEDIA_VFE_STATE checks bits at offset +2 dwords. However, it is possible to have MEDIA_VFE_STATE command with length = 0 + LENGTH_BIAS = 2. In that case check_cmd will read bits from the following command, or even past the end of the buffer. If the offset ends up outside of the command length, reject the command. Fixes: 351e3db2 ("drm/i915: Implement command buffer parsing logic") Signed-off-by:
Michal Srb <msrb@suse.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180205151745.29292-1-msrb@suse.comReviewed-by:
-
Michal Srb authored
The find_reg function was assuming that there is always at least one table in reg_tables. It is not always true. In case of VCS or VECS, the reg_tables is NULL and reg_table_count is 0, implying that no register-accessing commands are allowed. However, the command tables include commands such as MI_STORE_REGISTER_MEM. When trying to check such command, the find_reg would dereference NULL pointer. Now it will just return NULL meaning that the register was not found and the command will be rejected. Fixes: 76ff480e ("drm/i915/cmdparser: Use binary search for faster register lookup") Signed-off-by:
-
Ville Syrjälä authored
Deprecate the silly I915_SET_COLORKEY_NONE flag. The obvious way to disable colorkey is to just set flags to 0, which is exactly what the intel ddx has been doing all along. Currently when userspace sets the flags to 0, we end up in a funny state where colorkey is disabled, but various colorkey vs. scaling checks still consider colorkey to be enabled, and thus we don't allow plane scaling to kick in. In case there is some other userspace out there that actually uses this flag (unlikely as this is an i915 specific uapi) we'll keep on accepting it. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180202204231.27905-1-ville.syrjala@linux.intel.comReviewed-by:
-
Chris Wilson authored
Since commit 7b6da818 ("drm/i915: Restore the kernel context after a GPU reset on an idle engine") we submit a request following the engine reset. The intent is that we don't submit a request if the engine is busy (as it will restart active by itself) but we only checked to see if there were remaining requests in flight on the hardware and skipped checking to see if there were any ready requests that would be immediately submitted on restart (the same time as our new request would be). Having convinced the engine to appear idle in the previous patch, we can use intel_engine_is_idle() as a better test to only submit a new request if there are no pending requests. As it happens, this is tripping up igt/drv_selftest/live_hangcheck in CI as we overfill the kernel_context ringbuffer trigger an infinite recursion from within the reset. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104786 References: 7b6da818 ("drm/i915: Restore the kernel context after a GPU reset on an idle engine") Signed-off-by:
-
Chris Wilson authored
In preparation for the next patch, we want the engine to appear idle after a reset (if there are no requests in flight). For execlists, this entails clearing the active status on reset, it will be regenerated on restarting the engine after the reset. In the process, note that a couple of other status flags and checks could be moved into the describing function. Signed-off-by:
-
Chris Wilson authored
Avoid injecting hangs in to the i915->kernel_context in case the GPU reset leaves corruption in the context image in its wake (leading to continual failures and system hangs after the selftests are ostensibly complete). Use a sacrificial kernel_context instead. v2: Closing a context is tricky; export a function (for selftests) from i915_gem_context.c to get it right. Signed-off-by:
-
Chris Wilson authored
When injecting rapid resets, we must be careful to at least wait for the previous reset to have taken effect and the engine restarted. If we perform a second reset before that has happened, we will notice that the engine hasn't recovered and declare it lost, wedging the device and failing. In practice, since we wait for each hanging batch to start before injecting the reset, this too-fast-reset condition can only be triggered when moving onto the next engine in the test, so we need only wait for the existing reset to complete before switching engines. v2: Wrap up the wait inside a safety net to bail out in case of angry hw. Signed-off-by:
-
Chris Wilson authored
If we remember to cancel the signaler on a request when retiring it (after we know that the request has been signaled), we do not need to carry an additional request in the signaler itself. This prevents an issue whereby the signaler threads may be delayed and hold on to thousands of request references, causing severe memory fragmentation and premature oom (most noticeable on 32b snb due to the limited GFP_KERNEL and frequent use of inter-engine fences). v2: Rename first_signal(), document reads outside of locks. Signed-off-by:
-
Chris Wilson authored
During testing, we trigger a lot of resets on an unbannable context leading to massive amounts of irrelevant debug spam. Remove the ban_score accounting and message for the unbannable context so that we improve the signal:noise in the log messages for when the unexpected occurs. Signed-off-by:
-
Chris Wilson authored
Execlists is now enabled by default and included in the list of capabilities printed out to dmesg and beyond. We do not need to mention it again, every time we restart the engine, so kill the spam. Signed-off-by:
-
Chris Wilson authored
Dump each engine state when i915_gem_set_wedged() is called to give us some more clues as to why we had to terminate the GPU. Signed-off-by:
-
Chris Wilson authored
Provide the reason why we call intel_fbc_deactivate() so that debugging issues with FBC being delayed is clearer. Signed-off-by:
Jani Nikula <jani.nikula@intel.com>
-
Chris Wilson authored
The headers should be on a separate line for consistency, so add the missing trailing newline in a few intel_engine_dump() callers. Reported-by:
-
Chris Wilson authored
Since unbannable contexts are special and supposed not to be causing GPU hangs in the first place, make it clear when they are implicated in said hang. In practice, most unbannable contexts are those created by igt for the express purpose of throwing untold thousands of hangs at the GPU and wish to keep doing so to finish the test. Normally they are cleaned up, but it's when they or the other unbannable kernel contexts stay stuck in an erroneous state that we need to worry and so need highlighting. Suggested-by:
-
- 02 Feb, 2018 7 commits
-
-
Chris Wilson authored
As we ourselves cancel interrupts during reset by clearing the GTIIR, it is possible for the master IIR to indicate a pending IRQ for which we have already cleared from the GTIIR. In this case, the DRM_ERROR are intended and should not be flagged as an error. Signed-off-by:
-
Chris Wilson authored
Be paranoid and flush the GTIIR after clearing the CS interrupt to be sure it has taken before we re-enable the interrupt handler. We still see early interrupts following reset, the tasklet handling the mmio read before it has been written by the CS. This hopefully reduces the frequency to 0... References: https://bugs.freedesktop.org/show_bug.cgi?id=104262Signed-off-by:
-
Jani Nikula authored
Save some horizontal space. Reviewed-by:
David Weinehall <david.weinehall@linux.intel.com> Signed-off-by:
-
Michal Wajdeczko authored
We're using i915_inject_load_failure() to inject dummy faults during driver load, but since this is debug utility we shouldn't expose it in default config as it consumes both code and data. add/remove: 0/1 grow/shrink: 0/2 up/down: 0/-302 (-302) Function old new delta __i915_inject_load_failure 61 - -61 i915_gem_init 1331 1268 -63 i915_driver_load 5923 5745 -178 Total: Before=1177454, After=1177152, chg -0.03% add/remove: 0/1 grow/shrink: 0/0 up/down: 0/-4 (-4) Data old new delta i915_load_fail_count 4 - -4 Total: Before=56762, After=56758, chg -0.01% add/remove: 4/8 grow/shrink: 0/1 up/down: 245/-591 (-346) RO Data old new delta __param_str_inject_load_failure 20 - -20 __UNIQUE_ID_inject_load_failuretype200 34 - -34 __param_inject_load_failure 40 - -40 __func__ 4998 4896 -102 __UNIQUE_ID_inject_load_failure201 150 - -150 Total: Before=119095, After=118749, chg -0.29% Signed-off-by:
Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180201173248.3912-1-michal.wajdeczko@intel.comReviewed-by:
-
Jani Nikula authored
We have the max DP link rate info available in VBT since BDB version 216, included in child device config since commit c4fb60b9 ("drm/i915/bios: add DP max link rate to VBT child device struct"). Parse it and use it. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Jani Nikula authored
Make the limiting rate based instead of messing with the array size. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by:
-
Jani Nikula authored
This will be useful later on. Also move the functions around to not need forward declarations in subsequent patches. No functional changes. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by:
-
- 01 Feb, 2018 6 commits
-
-
Imre Deak authored
There is no requirement for doing the PCODE request polling atomically, so do that only for a short time switching to sleeping poll afterwards. The specification requires a 150usec timeout for the change notification, so let's use that for the atomic poll. Do the extra 2ms poll - needed as a workaround on BXT/GLK - in sleeping mode. v2: - rebase on v2 of patchset dropping the sandybridge_pcode_read/write refactoring (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
-
Imre Deak authored
Currently we see sporadic timeouts during CDCLK changing both on BXT and GLK as reported by the Bugzilla: ticket. It's easy to reproduce this by changing the frequency in a tight loop after blanking the display. The upper bound for the completion time is 800us based on my tests, so increase it from the current 500us to 2ms; with that I couldn't trigger the problem either on BXT or GLK. Note that timeouts happened during both the change notification and the voltage level setting PCODE request. (For the latter one BSpec doesn't require us to wait for completion before further HW programming.) This issue is similar to commit 2c7d0602 ("drm/i915/gen9: Fix PCODE polling during CDCLK change notification") but there the PCODE request does complete (as shown by the mbox busy flag), only the reply we get from PCODE indicates a failure. So there we keep resending the request until a success reply, here we just have to increase the timeout for the one PCODE request we send. v2: - s/snb_pcode_request/sandybridge_pcode_write_timeout/ (Ville) Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: <stable@vger.kernel.org> # v4.4+ Acked-by: Chris Wilson <chris@chris-wilson.co.uk> (v1) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103326Reviewed-by:
-
Michal Wajdeczko authored
In case of GuC initialization failure we may continue with driver load, but we wrongly assume that GuC is fully functional. This leads to the BUG as we attempt to access non-existing log vma. [26386.121085] BUG: unable to handle kernel NULL pointer dereference at 00000000000000a0 [26386.121225] IP: guc_log_runtime_create+0x23/0xe0 [i915] [26386.121763] Call Trace: [26386.121870] guc_log_late_setup+0xfd/0x140 [i915] [26386.121969] i915_driver_load+0x7ab/0x1730 [i915] [26386.122069] i915_pci_probe+0x2d/0x90 [i915] [26386.122089] pci_device_probe+0x9c/0x120 [26386.122107] driver_probe_device+0x2a9/0x490 [26386.122126] __driver_attach+0xd9/0xe0 [26386.122143] ? driver_probe_device+0x490/0x490 [26386.122158] bus_for_each_dev+0x57/0x90 [26386.122175] bus_add_driver+0x1eb/0x260 [26386.122190] ? 0xffffffffa069a000 [26386.122206] driver_register+0x52/0xc0 [26386.122220] ? 0xffffffffa069a000 [26386.122234] do_one_initcall+0x39/0x170 [26386.122252] ? kmem_cache_alloc_trace+0x1fd/0x2e0 [26386.122273] do_init_module+0x56/0x1ec [26386.122289] load_module+0x219e/0x2550 [26386.122309] ? vfs_read+0x121/0x140 [26386.122331] ? SyS_finit_module+0xa5/0xe0 [26386.122346] SyS_finit_module+0xa5/0xe0 [26386.122371] entry_SYSCALL_64_fastpath+0x22/0x8f Signed-off-by:
Sagar Arun Kamble <sagar.a.kamble@intel.com> Signed-off-by:
-
Michal Wajdeczko authored
We're freeing GuC error log in uc_fini_hw() that matches corresponding uc_init_hw() but we missed the point that this log object is copied on error path and in case of failure in uc_init_hw() we will leak this object as uc_fini_hw() is never called. If we free this log object as part of the late uC cleanup, where we also release other firmware objects, we can avoid this BUG: [70841.001413] BUG drm_i915_gem_object (Tainted: G U W ): Objects remaining in drm_i915_gem_object on __kmem_cache_shutdown() [70841.001436] INFO: Slab 0x00000000c94e41af objects=21 used=1 fp=0x000000001d60c40a flags=0x8000000000008100 [70841.001466] Call Trace: [70841.001471] dump_stack+0x5e/0x8e [70841.001476] slab_err+0x99/0xb0 [70841.001483] ? __slab_alloc.isra.24.constprop.29+0x62/0x70 [70841.001491] ? __kmalloc+0x1f5/0x320 [70841.001497] __kmem_cache_shutdown+0x18b/0x400 [70841.001505] shutdown_cache+0x13/0x1c0 [70841.001511] kmem_cache_destroy+0x1c2/0x240 [70841.001517] ? __mutex_unlock_slowpath+0x38/0x270 [70841.001559] i915_gem_load_cleanup+0xbc/0x130 [i915] [70841.001595] i915_driver_cleanup_early+0x11/0x60 [i915] [70841.001630] i915_driver_load+0x708/0x1720 [i915] [70841.001638] ? trace_hardirqs_on_caller+0xe2/0x1c0 [70841.001673] i915_pci_probe+0x2d/0x90 [i915] [70841.001680] pci_device_probe+0x9c/0x120 [70841.001687] driver_probe_device+0x2a9/0x490 [70841.001694] __driver_attach+0xd9/0xe0 [70841.001700] ? driver_probe_device+0x490/0x490 [70841.001705] bus_for_each_dev+0x57/0x90 [70841.001712] bus_add_driver+0x1eb/0x260 [70841.001717] ? 0xffffffffa0685000 [70841.001723] driver_register+0x52/0xc0 [70841.001728] ? 0xffffffffa0685000 [70841.001733] do_one_initcall+0x39/0x170 [70841.001739] ? rcu_read_lock_sched_held+0x6f/0x80 [70841.001746] ? kmem_cache_alloc_trace+0x27b/0x2e0 [70841.001753] do_init_module+0x56/0x1ec [70841.001759] load_module+0x219e/0x2550 [70841.001766] ? vfs_read+0x121/0x140 [70841.001774] ? SyS_finit_module+0xa5/0xe0 [70841.001779] SyS_finit_module+0xa5/0xe0 [70841.001788] entry_SYSCALL_64_fastpath+0x22/0x8f [70841.001806] INFO: Object 0x00000000eab7ed96 @offset=6208 [70841.001850] INFO: Allocated in i915_gem_object_create.part.32+0x1f/0x260 [i915] age=38 cpu=0 pid=2708 [70841.001861] kmem_cache_alloc+0x23d/0x2d0 [70841.001897] i915_gem_object_create.part.32+0x1f/0x260 [i915] [70841.001937] intel_guc_allocate_vma+0x15/0x100 [i915] [70841.001977] intel_guc_log_create+0x34/0x1c0 [i915] [70841.002014] intel_guc_init+0x5a/0x100 [i915] [70841.002051] intel_uc_init+0x3e/0xb0 [i915] [70841.002089] i915_gem_init+0x18e/0x540 [i915] [70841.002123] i915_driver_load+0xa7a/0x1720 [i915] [70841.002159] i915_pci_probe+0x2d/0x90 [i915] [70841.002165] pci_device_probe+0x9c/0x120 [70841.002171] driver_probe_device+0x2a9/0x490 [70841.002177] __driver_attach+0xd9/0xe0 [70841.002182] bus_for_each_dev+0x57/0x90 [70841.002188] bus_add_driver+0x1eb/0x260 [70841.002193] driver_register+0x52/0xc0 [70841.002198] do_one_initcall+0x39/0x170 [70841.002462] kmem_cache_destroy drm_i915_gem_object: Slab cache still has objects [70841.002491] Call Trace: [70841.002497] dump_stack+0x5e/0x8e [70841.002503] kmem_cache_destroy+0x1e0/0x240 [70841.002509] ? __mutex_unlock_slowpath+0x38/0x270 [70841.002551] i915_gem_load_cleanup+0xbc/0x130 [i915] [70841.002586] i915_driver_cleanup_early+0x11/0x60 [i915] [70841.002621] i915_driver_load+0x708/0x1720 [i915] [70841.002629] ? trace_hardirqs_on_caller+0xe2/0x1c0 [70841.002664] i915_pci_probe+0x2d/0x90 [i915] [70841.002671] pci_device_probe+0x9c/0x120 [70841.002678] driver_probe_device+0x2a9/0x490 [70841.002684] __driver_attach+0xd9/0xe0 [70841.002690] ? driver_probe_device+0x490/0x490 [70841.002696] bus_for_each_dev+0x57/0x90 [70841.002702] bus_add_driver+0x1eb/0x260 [70841.002708] ? 0xffffffffa0685000 [70841.002713] driver_register+0x52/0xc0 [70841.002719] ? 0xffffffffa0685000 [70841.002724] do_one_initcall+0x39/0x170 [70841.002731] ? rcu_read_lock_sched_held+0x6f/0x80 [70841.002737] ? kmem_cache_alloc_trace+0x27b/0x2e0 [70841.002745] do_init_module+0x56/0x1ec [70841.002751] load_module+0x219e/0x2550 [70841.002758] ? vfs_read+0x121/0x140 [70841.002766] ? SyS_finit_module+0xa5/0xe0 [70841.002772] SyS_finit_module+0xa5/0xe0 [70841.002781] entry_SYSCALL_64_fastpath+0x22/0x8f Signed-off-by:
-
Matthew Auld authored
Try to catch a bug we've seen in the wild where the shrinker purges the pd/pdp from under us while allocating our paging structures. References: https://bugs.freedesktop.org/show_bug.cgi?id=104773Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180131191453.12676-1-matthew.auld@intel.comReviewed-by:
-
Chris Wilson authored
Commit e2b763ca ("drm/i915: Remove bitmap tracking for used-pdpes") believed that because it did not insert its freshly allocated page directory into the pd tree, it was safe from the shrinker. I failed to heed the lesson learnt from commit dd19674b ("drm/i915: Remove bitmap tracking for used-ptes") that we need to pin all the levels in the tree before hitting the shrinker or else the shrinker may free an upper layer as we proceed to allocate the tree. Thus leaving dangling pointers everywhere and a GPF should we hit direct reclaim at just the wrong moment. CPU: 0 PID: 7374 Comm: chromium Tainted: P O 4.14.13-1-ARCH #1 Hardware name: Apple Inc. MacBookPro12,1/Mac-E43C1C25D4880AD6, BIOS MBP121.88Z.0167.B33.1706181928 06/18/2017 task: ffff994f696c2c40 task.stack: ffffb1a789d4c000 RIP: 0010:gen8_ppgtt_set_pde.isra.40+0x48/0x70 [i915] RSP: 0018:ffffb1a789d4f940 EFLAGS: 00010206 RAX: 81c1788cc4f68138 RBX: ffff994f54db8000 RCX: ffff994f696c2c40 RDX: 000000023bc73003 RSI: ffff994d598b6b80 RDI: ffff994f54db8000 RBP: ffff994d598b6b80 R08: 0000000000000000 R09: 0000000000000000 R10: ffffb1a789d4f550 R11: ffff994eaf3c3208 R12: 0000000000000027 R13: 0000000000005000 R14: 0000000004e8f000 R15: ffff994f54dba000 FS: 00007f585886aa00(0000) GS:ffff994faec00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000004ac8e8 CR3: 00000002552c8004 CR4: 00000000003606f0 Call Trace: gen8_ppgtt_alloc_pdp+0x178/0x320 [i915] gen8_ppgtt_alloc_4lvl+0x5f/0x150 [i915] ppgtt_bind_vma+0x30/0x70 [i915] i915_vma_bind+0x68/0xd0 [i915] __i915_vma_do_pin+0x2d6/0x3a0 [i915] eb_lookup_vmas+0x7a2/0xb50 [i915] i915_gem_do_execbuffer+0x4d7/0x10e0 [i915] ? sock_wfree+0x34/0x60 ? unix_stream_read_generic+0x1f9/0x7e0 ? import_iovec+0x37/0xd0 ? i915_gem_execbuffer2+0x5d/0x390 [i915] i915_gem_execbuffer2+0x1b7/0x390 [i915] ? i915_gem_execbuffer+0x2d0/0x2d0 [i915] drm_ioctl_kernel+0x59/0xb0 [drm] drm_ioctl+0x2d5/0x370 [drm] ? i915_gem_execbuffer+0x2d0/0x2d0 [i915] ? __seccomp_filter+0x3b/0x260 do_vfs_ioctl+0xa1/0x610 ? syscall_trace_enter+0xdb/0x2b0 SyS_ioctl+0x74/0x80 do_syscall_64+0x55/0x110 entry_SYSCALL64_slow_path+0x25/0x25 RIP: 0033:0x7f584fa82d27 RSP: 002b:00007ffee14a7828 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 000003b0126a1030 RCX: 00007f584fa82d27 RDX: 00007ffee14a7870 RSI: 0000000040406469 RDI: 0000000000000080 RBP: 00007ffee14a7870 R08: 0000000000000002 R09: 0000000000000077 R10: 00007f5839f2b780 R11: 0000000000000246 R12: 0000000040406469 R13: 0000000000000080 R14: 00007f5842b00040 R15: 0000000000000000 Code: 01 00 83 81 58 0a 00 00 01 48 2b 05 13 9d fd c9 48 c1 f8 06 48 c1 e0 0c 48 8d 04 d0 48 8b 56 08 48 03 05 0c 9d fd c9 48 83 ca 03 <48> 89 10 83 a9 58 0a 00 00 01 65 ff 0d 37 03 fb 3e 74 02 f3 c3 RIP: gen8_ppgtt_set_pde.isra.40+0x48/0x70 [i915] RSP: ffffb1a789d4f940 Reported-by:
Eric Blau <eblau@eblau.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104773 Fixes: e2b763ca ("drm/i915: Remove bitmap tracking for used-pdpes") References: dd19674b ("drm/i915: Remove bitmap tracking for used-ptes") Testcase: igt/drv_selftest/live_gtt (igt_ppgtt_shrink_boom) Signed-off-by:
-
