Chris Wilson
4797948071
drm/i915: Squash repeated awaits on the same fence
...
Track the latest fence waited upon on each context, and only add a new
asynchronous wait if the new fence is more recent than the recorded
fence for that context. This requires us to filter out unordered
timelines, which are noted by DMA_FENCE_NO_CONTEXT. However, in the
absence of a universal identifier, we have to use our own
i915->mm.unordered_timeline token.
v2: Throw around the debug crutches
v3: Inline the likely case of the pre-allocation cache being full.
v4: Drop the pre-allocation support, we can lose the most recent fence
in case of allocation failure -- it just means we may emit more awaits
than strictly necessary but will not break.
v5: Trim allocation size for leaf nodes, they only need an array of u32
not pointers.
v6: Create mock_timeline to tidy selftest writing
v7: s/intel_timeline_sync_get/intel_timeline_sync_is_later/ (Tvrtko)
v8: Prune the stale sync points when we idle.
v9: Include a small benchmark in the kselftests
v10: Separate the idr implementation into its own compartment. (Tvrkto)
v11: Refactor igt_sync kselftests to avoid deep nesting (Tvrkto)
v12: __sync_leaf_idx() to assert that p->height is 0 when checking leaves
v13: kselftests to investigate struct i915_syncmap itself (Tvrtko)
v14: Foray into ascii art graphs
v15: Take into account that the random lookup/insert does 2 prng calls,
not 1, when benchmarking, and use for_each_set_bit() (Tvrtko)
v16: Improved ascii art
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com >
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Link: http://patchwork.freedesktop.org/patch/msgid/20170503093924.5320-4-chris@chris-wilson.co.uk
2017-05-03 11:08:48 +01:00
Chris Wilson
ceae14bd4c
drm/i915: Lift timeline ordering to await_dma_fence
...
Currently we filter out repeated use of the same timeline in the low
level i915_gem_request_await_request(), after having added the
dependency on the old request. However, we can lift this to
i915_gem_request_await_dma_fence() (before the dependency is added)
using the observation that requests along the same timeline are
explicitly ordered via i915_add_request (along with the dependencies).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com >
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com >
Link: http://patchwork.freedesktop.org/patch/msgid/20170503093924.5320-3-chris@chris-wilson.co.uk
2017-05-03 11:08:47 +01:00
Chris Wilson
29ef3fa987
drm/i915: Unwrap top level fence-array
...
By first unwrapping an incoming fence-array into its child fences, we
can simplify the internal branching, and so avoid triggering a potential
bug in the next patch when not squashing the child fences on the same
timeline.
It will also have the advantage of keeping the (top-level) fence arrays
out of any fence/timeline caching since these are unordered timelines
but with a random context id.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com >
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Link: http://patchwork.freedesktop.org/patch/msgid/20170503093924.5320-2-chris@chris-wilson.co.uk
2017-05-03 11:08:46 +01:00
Chris Wilson
9431282832
drm/i915: Mark up clflushes as belonging to an unordered timeline
...
2 clflushes on two different objects are not ordered, and so do not
belong to the same timeline (context). Either we use a unique context
for each, or we reserve a special global context to mean unordered.
Ideally, we would reserve 0 to mean unordered (DMA_FENCE_NO_CONTEXT) to
have the same semantics everywhere.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Cc: Daniel Vetter <daniel.vetter@ffwll.ch >
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com >
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com >
Link: http://patchwork.freedesktop.org/patch/msgid/20170503093924.5320-1-chris@chris-wilson.co.uk
2017-05-03 11:08:45 +01:00
Mika Kuoppala
6b07b6d2bd
drm/i915: Use wait_for_atomic_us when waiting for gt fifo
...
Replace the handcrafter loop when checking for fifo slots
with atomic wait for. This brings this wait in line with
the other waits on register access. We also get a readable
timeout constraint, so make it to fail after 10ms.
Chris suggested that we should fail silently as the fifo debug
handler, now attached to unclaimed mmio handling, will take care of the
possible errors at later stage.
Note that the decision to wait was changed so that we avoid
allocating the first reserved entry. Nor do we reduce the count
if we fail the wait, removing the possiblity to wrap the
count if the hw fifo returned zero.
v2: remove unclaimed check on timeout (Chris)
v3: use void return (Chris)
References: https://bugs.freedesktop.org/show_bug.cgi?id=100247
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com >
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk >
Link: http://patchwork.freedesktop.org/patch/msgid/1491493182-31540-1-git-send-email-mika.kuoppala@intel.com
2017-05-03 12:47:33 +03:00
Mika Kuoppala
a338908c11
drm/i915: Move the GTFIFODBG to the common mmio dbg framework
...
Remove the per-mmio checking of the FIFO debug register into the common
conditional mmio debug handling. Based on patch from Chris Wilson.
v2: postpone warn on fifodbg for unclaimed reg debugs
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com >
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk >
2017-05-03 12:47:27 +03:00
Michal Wajdeczko
789a625158
drm/i915/guc: Enable send function only after successful init
...
It is safer to setup valid send function after successful GuC
hardware initialization. In addition we prepare placeholder
where we can setup any alternate GuC communication mechanism.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com >
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com >
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com >
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com >
Link: http://patchwork.freedesktop.org/patch/msgid/20170502103243.54940-1-michal.wajdeczko@intel.com
[ickle: Fixup ENODEV for an impossible error path]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
2017-05-02 13:04:00 +01:00
Joonas Lahtinen
cefcff8f93
drm/i915: Do not leak dev_priv->l3_parity.remap_info[]
...
Add intel_irq_fini() for placing the deinitialization code,
starting with freeing dev_priv->l3_parity.remap_info[].
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com >
Cc: Chris Wilson <chris@chris-wilson.co.uk >
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Cc: Mika Kuoppala <mika.kuoppala@intel.com >
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk >
Link: http://patchwork.freedesktop.org/patch/msgid/1493366319-18515-1-git-send-email-joonas.lahtinen@linux.intel.com
2017-05-02 12:09:13 +03:00
Daniel Vetter
a021880f78
drm/i915: Update DRIVER_DATE to 20170502
...
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch >
2017-05-02 09:29:47 +02:00
Dave Airlie
73ba2d5c2b
Merge tag 'drm-intel-next-fixes-2017-04-27' of git://anongit.freedesktop.org/git/drm-intel into drm-next
...
drm/i915 and gvt fixes for drm-next/v4.12
* tag 'drm-intel-next-fixes-2017-04-27' of git://anongit.freedesktop.org/git/drm-intel:
drm/i915: Confirm the request is still active before adding it to the await
drm/i915: Avoid busy-spinning on VLV_GLTC_PW_STATUS mmio
drm/i915/selftests: Allocate inode/file dynamically
drm/i915: Fix system hang with EI UP masked on Haswell
drm/i915: checking for NULL instead of IS_ERR() in mock selftests
drm/i915: Perform link quality check unconditionally during long pulse
drm/i915: Fix use after free in lpe_audio_platdev_destroy()
drm/i915: Use the right mapping_gfp_mask for final shmem allocation
drm/i915: Make legacy cursor updates more unsynced
drm/i915: Apply a cond_resched() to the saturated signaler
drm/i915: Park the signaler before sleeping
drm/i915/gvt: fix a bounds check in ring_id_to_context_switch_event()
drm/i915/gvt: Fix PTE write flush for taking runtime pm properly
drm/i915/gvt: remove some debug messages in scheduler timer handler
drm/i915/gvt: add mmio init for virtual display
drm/i915/gvt: use directly assignment for structure copying
drm/i915/gvt: remove redundant ring id check which cause significant CPU misprediction
drm/i915/gvt: remove redundant platform check for mocs load/restore
drm/i915/gvt: Align render mmio list to cacheline
drm/i915/gvt: cleanup some too chatty scheduler message
2017-04-29 05:50:27 +10:00
Ander Conselvan de Oliveira
3acbec03b3
drm/i915/glk: Fix DSI "*ERROR* ULPS is still active" messages
...
The sequence in glk_dsi_device_ready() enters ULPS then waits until it is
*not* active to then disable it. The correct sequence according to the
spec is to enter ULPS then wait until the GLK_ULPS_NOT_ACTIVE bit is
zero, i.e., ULPS is active, and then disable ULPS.
Fixing the condition gets rid of the following spurious error messages:
[drm:glk_dsi_device_ready [i915]] *ERROR* ULPS is still active
Fixes: 4644848369m.deepak@intel.com >
Cc: Madhav Chauhan <madhav.chauhan@intel.com >
Cc: Jani Nikula <jani.nikula@intel.com >
Cc: Daniel Vetter <daniel.vetter@intel.com >
Cc: Jani Nikula <jani.nikula@linux.intel.com >
Cc: intel-gfx@lists.freedesktop.org
Cc: <drm-intel-fixes@lists.freedesktop.org >
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com >
Reviewed-by: Madhav Chauhan <madhav.chauhan@intel.com >
Link: http://patchwork.freedesktop.org/patch/msgid/20170428080222.6147-1-ander.conselvan.de.oliveira@intel.com
2017-04-28 17:09:06 +03:00
Joonas Lahtinen
5de9232040
drm/i915: Capture CCID on ILK
...
CCID register existed already on ILK according to the PRM (Chris
verified the address to match too).
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com >
Cc: Chris Wilson <chris@chris-wilson.co.uk >
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com >
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk >
Link: http://patchwork.freedesktop.org/patch/msgid/1493366019-18380-1-git-send-email-joonas.lahtinen@linux.intel.com
2017-04-28 12:11:59 +03:00
Joonas Lahtinen
ea117b8ddc
drm/i915: Reset ILK during GEM sanitization
...
ILK should survive a reset without display corruption.
Suggested-by: Chris Wilson <chris@chris-wilson.co.uk >
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com >
Cc: Chris Wilson <chris@chris-wilson.co.uk >
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com >
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk >
2017-04-28 12:11:59 +03:00
Joonas Lahtinen
f2e4d76ec2
drm/i915: Eliminate HAS_HW_CONTEXTS
...
HAS_HW_CONTEXTS is misleading condition for GPU reset and CCID,
replace it with Gen specific (to be updated in next patches).
HAS_HW_CONTEXTS in i915_l3_write is bogus because each HAS_L3_DPF
match also has .has_hw_contexts = 1 set.
This leads to us being able to get rid of the property completely.
v2:
- Keep the checks at Gen6 for no functional change (Ville)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com >
Cc: Chris Wilson <chris@chris-wilson.co.uk >
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Cc: Mika Kuoppala <mika.kuoppala@intel.com >
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk >
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com >
2017-04-28 12:11:59 +03:00
Joonas Lahtinen
63ffbcdadc
drm/i915: Sanitize engine context sizes
...
Pre-calculate engine context size based on engine class and device
generation and store it in the engine instance.
v2:
- Squash and get rid of hw_context_size (Chris)
v3:
- Move after MMIO init for probing on Gen7 and 8 (Chris)
- Retained rounding (Tvrtko)
v4:
- Rebase for deferred legacy context allocation
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com >
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com >
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com >
Cc: Chris Wilson <chris@chris-wilson.co.uk >
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com >
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Cc: Oscar Mateo <oscar.mateo@intel.com >
Cc: Zhenyu Wang <zhenyuw@linux.intel.com >
Cc: intel-gvt-dev@lists.freedesktop.org
Acked-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk >
2017-04-28 12:11:59 +03:00
Tvrtko Ursulin
a3662830e1
drm/i915/guc: Fix sleep under spinlock during reset
...
Looks like intel_guc_reset had the ability to sleep under the
uncore spinlock since forever but it wasn't detected until the
recent changes annotated the wait for register with might_sleep.
I have fixed it by removing holding of the uncore spinlock over
the call to gen6_hw_domain_reset, since I do not see that is
really needed. But there is always a possibility I am missing
some nasty detail so please double check.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Cc: Chris Wilson <chris@chris-wilson.co.uk >
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com >
Cc: Arkadiusz Hiler <arkadiusz.hiler@intel.com >
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com >
Cc: Oscar Mateo <oscar.mateo@intel.com >
Acked-by: Michel Thierry <michel.thierry@intel.com >
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com >
2017-04-28 08:58:15 +01:00
Chris Wilson
3204c343bb
drm/i915: Defer context state allocation for legacy ring submission
...
Almost from the outset for execlists, we used deferred allocation of the
logical context and rings. Then we ported the infrastructure for pinning
contexts back to legacy, and so now we are able to also implement
deferred allocation for context objects prior to first use on the legacy
submission.
v2: We still need to differentiate between legacy engines, Joonas is
fixing that but I want this first ;) (Joonas)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com >
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com >
Link: http://patchwork.freedesktop.org/patch/msgid/20170427104651.22394-1-chris@chris-wilson.co.uk
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com >
2017-04-27 12:22:13 +01:00
Michel Thierry
e3895af8bb
drm/i915: Rename gen8_(un)request_engine_reset to gen8_reset_engine_start/cancel
...
As all other functions related to resetting engines are using
reset_engine.
v2: remove _request_ and use start/cancel instead (Chris)
Cc: Chris Wilson <chris@chris-wilson.co.uk >
Signed-off-by: Michel Thierry <michel.thierry@intel.com >
Link: http://patchwork.freedesktop.org/patch/msgid/20170418202335.35232-3-michel.thierry@intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk >
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
2017-04-27 09:11:34 +01:00
Michel Thierry
56306c6e93
drm/i915: Fix stale comment about I915_RESET_IN_PROGRESS flag
...
It has been replaced by I915_RESET_BACKOFF / I915_RESET_HANDOFF.
Signed-off-by: Michel Thierry <michel.thierry@intel.com >
Link: http://patchwork.freedesktop.org/patch/msgid/20170418202335.35232-2-michel.thierry@intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk >
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
2017-04-27 09:11:07 +01:00
Ander Conselvan de Oliveira
46649d8b6c
drm/i915/glk: Don't allow 12 bpc when htotal is too big
...
Display workaround #1139 for Geminilake instructs us to restrict HDMI
to 8 bpc when htotal is greater than 5460. Otherwise, the pipe is unable
to generate a proper signal and is left in a state where corruption is
seen with other modes.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100440
Cc: Shashank Sharma <shashank.sharma@intel.com >
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com >
Reviewed-by: Shashank Sharma <shashank.sharma@intel.com >
Link: http://patchwork.freedesktop.org/patch/msgid/20170424104718.26448-1-ander.conselvan.de.oliveira@intel.com
2017-04-26 19:03:36 +03:00
Chris Wilson
88326ef05b
drm/i915: Confirm the request is still active before adding it to the await
...
Although we do check the completion-status of the request before
actually adding a wait on it (either to its submit fence or its
completion dma-fence), we currently do not check before adding it to the
dependency lists.
In fact, without checking for a completed request we may try to use the
signaler after it has been retired and its dependency tree freed:
[ 60.044057] BUG: KASAN: use-after-free in __list_add_valid+0x1d/0xd0 at addr ffff880348c9e6a0
[ 60.044118] Read of size 8 by task gem_exec_fence/530
[ 60.044164] CPU: 1 PID: 530 Comm: gem_exec_fence Tainted: G E 4.11.0-rc7+ #46
[ 60.044226] Hardware name: ��������������������������������� ���������������������������������/���������������������������������, BIOS RYBDWi35.86A.0246.2
[ 60.044290] Call Trace:
[ 60.044337] dump_stack+0x4d/0x6a
[ 60.044383] kasan_object_err+0x21/0x70
[ 60.044435] kasan_report+0x225/0x4e0
[ 60.044488] ? __list_add_valid+0x1d/0xd0
[ 60.044534] ? kasan_kmalloc+0xad/0xe0
[ 60.044587] __asan_load8+0x5e/0x70
[ 60.044639] __list_add_valid+0x1d/0xd0
[ 60.044788] __i915_priotree_add_dependency+0x67/0x130 [i915]
[ 60.044895] i915_gem_request_await_request+0xa8/0x370 [i915]
[ 60.044974] i915_gem_request_await_dma_fence+0x129/0x140 [i915]
[ 60.045049] i915_gem_do_execbuffer.isra.37+0xb0a/0x26b0 [i915]
[ 60.045077] ? save_stack+0xb1/0xd0
[ 60.045105] ? save_stack_trace+0x1b/0x20
[ 60.045132] ? save_stack+0x46/0xd0
[ 60.045158] ? kasan_kmalloc+0xad/0xe0
[ 60.045184] ? __kmalloc+0xd8/0x670
[ 60.045229] ? drm_ioctl+0x359/0x640 [drm]
[ 60.045256] ? SyS_ioctl+0x41/0x70
[ 60.045330] ? i915_vma_move_to_active+0x540/0x540 [i915]
[ 60.045360] ? tty_insert_flip_string_flags+0xa1/0xf0
[ 60.045387] ? tty_flip_buffer_push+0x63/0x70
[ 60.045414] ? remove_wait_queue+0xa9/0xc0
[ 60.045441] ? kasan_unpoison_shadow+0x35/0x50
[ 60.045467] ? kasan_kmalloc+0xad/0xe0
[ 60.045494] ? kasan_check_write+0x14/0x20
[ 60.045568] i915_gem_execbuffer2+0xdb/0x2a0 [i915]
[ 60.045616] drm_ioctl+0x359/0x640 [drm]
[ 60.045705] ? i915_gem_execbuffer+0x5a0/0x5a0 [i915]
[ 60.045751] ? drm_version+0x150/0x150 [drm]
[ 60.045778] ? compat_start_thread+0x60/0x60
[ 60.045805] ? plist_del+0xda/0x1a0
[ 60.045833] do_vfs_ioctl+0x12e/0x910
[ 60.045860] ? ioctl_preallocate+0x130/0x130
[ 60.045886] ? pci_mmcfg_check_reserved+0xc0/0xc0
[ 60.045913] ? vfs_write+0x196/0x240
[ 60.045939] ? __fget_light+0xa7/0xc0
[ 60.045965] SyS_ioctl+0x41/0x70
[ 60.045991] entry_SYSCALL_64_fastpath+0x17/0x98
[ 60.046017] RIP: 0033:0x7feb2baefc47
[ 60.046042] RSP: 002b:00007fff56d28e58 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
[ 60.046075] RAX: ffffffffffffffda RBX: 00007fff56d290a8 RCX: 00007feb2baefc47
[ 60.046102] RDX: 00007fff56d29050 RSI: 00000000c0406469 RDI: 0000000000000003
[ 60.046129] RBP: 00007fff56d29050 R08: 000055ecc4cd27d0 R09: 00007feb2bda8600
[ 60.046154] R10: 0000000000000073 R11: 0000000000000246 R12: 00000000c0406469
[ 60.046177] R13: 0000000000000003 R14: 000000000000000f R15: 0000000000000099
[ 60.046203] Object at ffff880348c9e680, in cache i915_dependency size: 64
[ 60.046225] Allocated:
[ 60.046246] PID = 530
[ 60.046269] save_stack_trace+0x1b/0x20
[ 60.046292] save_stack+0x46/0xd0
[ 60.046318] kasan_kmalloc+0xad/0xe0
[ 60.046343] kasan_slab_alloc+0x12/0x20
[ 60.046368] kmem_cache_alloc+0xab/0x650
[ 60.046445] i915_gem_request_await_request+0x88/0x370 [i915]
[ 60.046559] i915_gem_request_await_dma_fence+0x129/0x140 [i915]
[ 60.046705] i915_gem_do_execbuffer.isra.37+0xb0a/0x26b0 [i915]
[ 60.046849] i915_gem_execbuffer2+0xdb/0x2a0 [i915]
[ 60.046936] drm_ioctl+0x359/0x640 [drm]
[ 60.046987] do_vfs_ioctl+0x12e/0x910
[ 60.047038] SyS_ioctl+0x41/0x70
[ 60.047090] entry_SYSCALL_64_fastpath+0x17/0x98
[ 60.047139] Freed:
[ 60.047179] PID = 530
[ 60.047223] save_stack_trace+0x1b/0x20
[ 60.047269] save_stack+0x46/0xd0
[ 60.047317] kasan_slab_free+0x72/0xc0
[ 60.047366] kmem_cache_free+0x39/0x160
[ 60.047512] i915_gem_request_retire+0x83f/0x930 [i915]
[ 60.047657] i915_gem_request_alloc+0x166/0x600 [i915]
[ 60.047799] i915_gem_do_execbuffer.isra.37+0xad8/0x26b0 [i915]
[ 60.047897] i915_gem_execbuffer2+0xdb/0x2a0 [i915]
[ 60.047942] drm_ioctl+0x359/0x640 [drm]
[ 60.047968] do_vfs_ioctl+0x12e/0x910
[ 60.047993] SyS_ioctl+0x41/0x70
[ 60.048019] entry_SYSCALL_64_fastpath+0x17/0x98
[ 60.048044] Memory state around the buggy address:
[ 60.048066] ffff880348c9e580: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc
[ 60.048105] ffff880348c9e600: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc
[ 60.048138] >ffff880348c9e680: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
[ 60.048170] ^
[ 60.048191] ffff880348c9e700: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc
[ 60.048225] ffff880348c9e780: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc
Note to hit the use-after-free requires us to be passed back a request
via a fence-array, that is from explicit fencing accumulated into a
sync-file fence-array.
Fixes: 52e5420907chris@chris-wilson.co.uk >
Reviewed-by: Michał Winiarski <michal.winiarski@intel.com >
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com >
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Link: http://patchwork.freedesktop.org/patch/msgid/20170422081537.6468-1-chris@chris-wilson.co.uk
(cherry picked from commit ade0b0c965jani.nikula@intel.com >
2017-04-26 16:28:47 +03:00
Chris Wilson
96dabe99ca
drm/i915: Avoid busy-spinning on VLV_GLTC_PW_STATUS mmio
...
The busy-spin, as the first stage of intel_wait_for_register(), is
currently under suspicion for causing:
[ 62.034926] NMI watchdog: Watchdog detected hard LOCKUP on cpu 1
[ 62.034928] Modules linked in: i2c_dev i915 intel_gtt drm_kms_helper prime_numbers
[ 62.034932] CPU: 1 PID: 183 Comm: kworker/1:2 Not tainted 4.11.0-rc7+ #471
[ 62.034933] Hardware name: / , BIOS PYBSWCEL.86A.0027.2015.0507.1758 05/07/2015
[ 62.034934] Workqueue: pm pm_runtime_work
[ 62.034936] task: ffff880275a04ec0 task.stack: ffffc900002d8000
[ 62.034936] RIP: 0010:__intel_wait_for_register_fw+0x77/0x1a0 [i915]
[ 62.034937] RSP: 0018:ffffc900002dbc38 EFLAGS: 00000082
[ 62.034939] RAX: ffffc90003530094 RBX: 0000000000130094 RCX: 0000000000000001
[ 62.034940] RDX: 00000000000000a1 RSI: ffff88027fd15e58 RDI: 0000000000000000
[ 62.034941] RBP: ffffc900002dbc78 R08: 0000000000000002 R09: 0000000000000000
[ 62.034942] R10: ffffc900002dbc18 R11: ffff880276429dd0 R12: ffff8802707c0000
[ 62.034943] R13: 00000000000000a0 R14: 0000000000000000 R15: 00000000fffefc10
[ 62.034945] FS: 0000000000000000(0000) GS:ffff88027fd00000(0000) knlGS:0000000000000000
[ 62.034945] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 62.034947] CR2: 00007ffd3cd98ff8 CR3: 0000000274c19000 CR4: 00000000001006e0
[ 62.034947] Call Trace:
[ 62.034948] intel_wait_for_register+0x77/0x140 [i915]
[ 62.034949] vlv_suspend_complete+0x23/0x5b0 [i915]
[ 62.034950] intel_runtime_suspend+0x16c/0x2a0 [i915]
[ 62.034950] pci_pm_runtime_suspend+0x50/0x180
[ 62.034951] ? pci_pm_runtime_resume+0xa0/0xa0
[ 62.034952] __rpm_callback+0xc5/0x210
[ 62.034953] rpm_callback+0x1f/0x80
[ 62.034953] ? pci_pm_runtime_resume+0xa0/0xa0
[ 62.034954] rpm_suspend+0x118/0x580
[ 62.034955] pm_runtime_work+0x64/0x90
[ 62.034956] process_one_work+0x1bb/0x3e0
[ 62.034956] worker_thread+0x46/0x4f0
[ 62.034957] ? __schedule+0x18b/0x610
[ 62.034958] kthread+0xff/0x140
[ 62.034958] ? process_one_work+0x3e0/0x3e0
[ 62.034959] ? kthread_create_on_node+
and related hard lockups in CI for byt and bsw.
Note this effectively reverts commits 41ce405e68b27366958841ce405e68b273669588https://bugs.freedesktop.org/show_bug.cgi?id=100718
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com >
Cc: Tomi Sarvela <tomi.p.sarvela@intel.com >
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Link: http://patchwork.freedesktop.org/patch/msgid/20170421135815.11897-1-chris@chris-wilson.co.uk
Tested-by: Tomi Sarvela <tomi.p.sarvela@intel.com >
(cherry picked from commit 3dd14c04d7jani.nikula@intel.com >
2017-04-26 16:28:42 +03:00
Chris Wilson
b162d47e14
drm/i915/selftests: Allocate inode/file dynamically
...
Avoid having too large a stack by creating the fake struct inode/file on
the heap instead.
drivers/gpu/drm/i915/selftests/mock_drm.c: In function 'mock_file':
drivers/gpu/drm/i915/selftests/mock_drm.c:46:1: error: the frame size of 1328 bytes is larger than 1280 bytes [-Werror=frame-larger-than=]
drivers/gpu/drm/i915/selftests/mock_drm.c: In function 'mock_file_free':
drivers/gpu/drm/i915/selftests/mock_drm.c:54:1: error: the frame size of 1312 bytes is larger than 1280 bytes [-Werror=frame-larger-than=]
Reported-by: Arnd Bergmann <arnd@arndb.de >
Fixes: 66d9cb5d80chris@chris-wilson.co.uk >
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com >
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Cc: Matthew Auld <matthew.auld@intel.com >
Cc: Arnd Bergmann <arnd@arndb.de >
Acked-by: Arnd Bergmann <arnd@arndb.de >
Link: http://patchwork.freedesktop.org/patch/msgid/20170419094143.16922-2-chris@chris-wilson.co.uk
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com >
(cherry picked from commit 2310b3c952jani.nikula@intel.com >
2017-04-26 16:28:34 +03:00
Mika Kuoppala
acf2dc2266
drm/i915: Fix system hang with EI UP masked on Haswell
...
Previously with commit a9c1f90c8ehttps://bugs.freedesktop.org/show_bug.cgi?id=100672
Cc: Chris Wilson <chris@chris-wilson.co.uk >
Cc: stable@vger.kernel.org
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com >
Acked-by: Chris Wilson <chris@chris-wilson.co.uk >
Link: http://patchwork.freedesktop.org/patch/msgid/1492082127-29007-1-git-send-email-mika.kuoppala@intel.com
(cherry picked from commit 3396a27385jani.nikula@intel.com >
2017-04-26 16:28:28 +03:00
Dan Carpenter
5af9e672b8
drm/i915: checking for NULL instead of IS_ERR() in mock selftests
...
i915_gem_request_alloc() uses error pointers. It never returns NULLs.
Fixes: 0daf0113cfdan.carpenter@oracle.com >
Link: http://patchwork.freedesktop.org/patch/msgid/20170413195217.GA26108@mwanda
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk >
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
(cherry picked from commit be02f75564jani.nikula@intel.com >
2017-04-26 16:28:24 +03:00
Ville Syrjälä
dea6559398
drm/i915: Perform link quality check unconditionally during long pulse
...
Apparently some DP sinks are a little nuts and cause HPD to drop
intermittently during modesets. This happens eg. on an ASUS PB287Q.
In oder to recover from this we can't really use the previous
connector status to determine if the link needs retraining, so let's
just ignore that piece of information and do the retrain
unconditionally. We do of course still check whether the link is
supposed to be running or not.
To actually get read out the EDID and update things properly we
also need to nuke the goto out added by commit 7d23e3c37bstable@vger.kernel.org
Cc: Manasi Navare <manasi.d.navare@intel.com >
Cc: Palmer Dabbelt <palmer@dabbelt.com >
Reported-by: Palmer Dabbelt <palmer@dabbelt.com >
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99766
References: https://lists.freedesktop.org/archives/intel-gfx/2017-February/119779.html
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk >
Link: http://patchwork.freedesktop.org/patch/msgid/20170412193017.21029-1-ville.syrjala@linux.intel.com
(cherry picked from commit 1a36147bb9jani.nikula@intel.com >
2017-04-26 16:28:19 +03:00
Chris Wilson
dde7b00e4c
drm/i915: Fix use after free in lpe_audio_platdev_destroy()
...
[31908.547136] BUG: KASAN: use-after-free in intel_lpe_audio_teardown+0x78/0xb0 [i915] at addr ffff8801f7788358
[31908.547297] Read of size 8 by task drv_selftest/3781
[31908.547405] CPU: 0 PID: 3781 Comm: drv_selftest Tainted: G BU W 4.10.0+ #451
[31908.547553] Hardware name: / , BIOS PYBSWCEL.86A.0027.2015.0507.1758 05/07/2015
[31908.547682] Call Trace:
[31908.547772] dump_stack+0x68/0x9f
[31908.547857] kasan_object_err+0x1c/0x70
[31908.547947] kasan_report_error+0x1f1/0x4f0
[31908.548038] ? kfree+0xaa/0x170
[31908.548121] kasan_report+0x34/0x40
[31908.548211] ? klist_children_get+0x20/0x30
[31908.548472] ? intel_lpe_audio_teardown+0x78/0xb0 [i915]
[31908.548567] __asan_load8+0x5e/0x70
[31908.548824] intel_lpe_audio_teardown+0x78/0xb0 [i915]
[31908.549080] intel_audio_deinit+0x28/0x80 [i915]
[31908.549315] i915_driver_unload+0xe4/0x360 [i915]
[31908.549551] ? i915_driver_load+0x1d70/0x1d70 [i915]
[31908.549651] ? trace_hardirqs_on+0xd/0x10
[31908.549885] i915_pci_remove+0x23/0x30 [i915]
[31908.549978] pci_device_remove+0x5c/0x100
[31908.550069] device_release_driver_internal+0x1db/0x2e0
[31908.550165] driver_detach+0x68/0xc0
[31908.550256] bus_remove_driver+0x8b/0x150
[31908.550346] driver_unregister+0x3e/0x60
[31908.550439] pci_unregister_driver+0x1d/0x110
[31908.550531] ? find_module_all+0x7a/0xa0
[31908.550791] i915_exit+0x1a/0x87 [i915]
[31908.550881] SyS_delete_module+0x264/0x2c0
[31908.550971] ? free_module+0x430/0x430
[31908.551064] ? trace_hardirqs_off_caller+0x16/0x110
[31908.551159] ? trace_hardirqs_on_caller+0x16/0x280
[31908.551256] ? trace_hardirqs_on_thunk+0x1a/0x1c
[31908.551350] entry_SYSCALL_64_fastpath+0x1c/0xb1
[31908.551440] RIP: 0033:0x7f1d67312ec7
[31908.551520] RSP: 002b:00007ffebe34e888 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0
[31908.551650] RAX: ffffffffffffffda RBX: ffffffff811123f6 RCX: 00007f1d67312ec7
[31908.551743] RDX: 0000000000000000 RSI: 0000000000000800 RDI: 0000560d0af476b8
[31908.551837] RBP: ffff880233d87f98 R08: 0000000000000000 R09: 00007ffebe34e8b8
[31908.551930] R10: 00007f1d68adf8c0 R11: 0000000000000206 R12: 0000000000000000
[31908.552023] R13: 0000560d0af46440 R14: 0000000000000034 R15: 00007ffebe34d860
[31908.552121] ? trace_hardirqs_off_caller+0x16/0x110
[31908.552217] Object at ffff8801f7788000, in cache kmalloc-2048 size: 2048
[31908.552306] Allocated:
[31908.552377] PID = 3781
[31908.552456] save_stack_trace+0x16/0x20
[31908.552539] kasan_kmalloc+0xee/0x190
[31908.552627] __kmalloc+0xdb/0x1b0
[31908.552713] platform_device_alloc+0x27/0x90
[31908.552804] platform_device_register_full+0x36/0x220
[31908.553066] intel_lpe_audio_init+0x41e/0x570 [i915]
[31908.553320] intel_audio_init+0xd/0x40 [i915]
[31908.553552] i915_driver_load+0x13f5/0x1d70 [i915]
[31908.553788] i915_pci_probe+0x65/0xe0 [i915]
[31908.553881] pci_device_probe+0xda/0x140
[31908.553969] driver_probe_device+0x400/0x660
[31908.554058] __driver_attach+0x11c/0x120
[31908.554147] bus_for_each_dev+0xe6/0x150
[31908.554237] driver_attach+0x26/0x30
[31908.554325] bus_add_driver+0x26b/0x3b0
[31908.554412] driver_register+0xce/0x190
[31908.554502] __pci_register_driver+0xaf/0xc0
[31908.554589] 0xffffffffa0550063
[31908.554675] do_one_initcall+0x8b/0x1e0
[31908.554764] do_init_module+0x102/0x325
[31908.554852] load_module+0x3aad/0x45e0
[31908.554944] SyS_finit_module+0x169/0x1a0
[31908.555033] entry_SYSCALL_64_fastpath+0x1c/0xb1
[31908.555119] Freed:
[31908.555188] PID = 3781
[31908.555266] save_stack_trace+0x16/0x20
[31908.555349] kasan_slab_free+0xb0/0x180
[31908.555436] kfree+0xaa/0x170
[31908.555520] platform_device_release+0x76/0x80
[31908.555610] device_release+0x45/0xe0
[31908.555698] kobject_put+0x11f/0x260
[31908.555785] put_device+0x12/0x20
[31908.555871] platform_device_unregister+0x1b/0x20
[31908.556135] intel_lpe_audio_teardown+0x5c/0xb0 [i915]
[31908.556390] intel_audio_deinit+0x28/0x80 [i915]
[31908.556622] i915_driver_unload+0xe4/0x360 [i915]
[31908.556858] i915_pci_remove+0x23/0x30 [i915]
[31908.556948] pci_device_remove+0x5c/0x100
[31908.557037] device_release_driver_internal+0x1db/0x2e0
[31908.557129] driver_detach+0x68/0xc0
[31908.557217] bus_remove_driver+0x8b/0x150
[31908.557304] driver_unregister+0x3e/0x60
[31908.557394] pci_unregister_driver+0x1d/0x110
[31908.557653] i915_exit+0x1a/0x87 [i915]
[31908.557741] SyS_delete_module+0x264/0x2c0
[31908.557834] entry_SYSCALL_64_fastpath+0x1c/0xb1
[31908.557919] Memory state around the buggy address:
[31908.558005] ffff8801f7788200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[31908.558127] ffff8801f7788280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[31908.558255] >ffff8801f7788300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[31908.558374] ^
[31908.558467] ffff8801f7788380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[31908.558595] ffff8801f7788400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
v2: Just leak the memory (8 bytes) as freeing it ourselves is not safe,
and we need to coordinate a proper fix in platform_device itself.
Fixes: eef57324d9https://bugs.freedesktop.org/show_bug.cgi?id=99952
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com >
Cc: Jerome Anand <jerome.anand@intel.com >
Cc: Jani Nikula <jani.nikula@intel.com >
Cc: Takashi Iwai <tiwai@suse.de >
Link: http://patchwork.freedesktop.org/patch/msgid/20170412080251.30648-1-chris@chris-wilson.co.uk
Reviewed-by: Takashi Iwai <tiwai@suse.de >
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
(cherry picked from commit 48ae80741djani.nikula@intel.com >
2017-04-26 16:28:15 +03:00
Chris Wilson
bdb57b8dca
drm/i915: Use the right mapping_gfp_mask for final shmem allocation
...
Many sightings report the greater prevalence of allocation failures.
This is all due to the incorrect use of mapping_gfp_constraint(), so
remove it in favour of just querying the mapping_gfp_mask() which are
the exact gfp_t we wanted in the first place.
We still do expect a higher chance of reporting ENOMEM, as that is the
intention of using __GFP_NORETRY -- to fail rather than oom after having
reclaimed from our bo caches, and having done a direct|kswapd reclaim
pass.
Reported-by: Jason Ekstrand <jason.ekstrand@intel.com >
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100594
Fixes: 24f8e00a8achris@chris-wilson.co.uk >
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com >
Cc: Daniel Vetter <daniel.vetter@ffwll.ch >
Link: http://patchwork.freedesktop.org/patch/msgid/20170405221514.23251-1-chris@chris-wilson.co.uk
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com >
(cherry picked from commit b268d9fe0fjani.nikula@intel.com >
2017-04-26 16:28:08 +03:00
Ville Syrjälä
440df938b4
drm/i915: Make legacy cursor updates more unsynced
...
We're clearing the legacy_cursor_update flag before calling
drm_atomic_helper_setup_commit() which means the helper will
wait for the flip to complete before cleaning up the framebuffers.
That's not what we want for the legacy cursor, so let's clear
the flag after setting up the commit.
Also toss in a FIXME about solving these problems in a nicer
way using the fabled vblank workers.
v2: Also unsync with legacy page flips
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com >
Cc: Daniel Vetter <daniel.vetter@ffwll.ch >
Cc: Uwe Kleine-König <uwe@kleine-koenig.org >
Cc: Rafael Ristovski <rafael.ristovski@gmail.com >
Fixes: a5509abda4ville.syrjala@linux.intel.com >
Link: http://patchwork.freedesktop.org/patch/msgid/20170329142123.5923-1-ville.syrjala@linux.intel.com
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com >
(cherry picked from commit 8952030440jani.nikula@intel.com >
2017-04-26 16:28:03 +03:00
Chris Wilson
d445aaaac0
drm/i915: Apply a cond_resched() to the saturated signaler
...
If the engine is continually completing nops, we can saturate the
signaler and keep it working indefinitely. This angers the NMI watchdog!
A good example is to disable semaphores on snb and run igt/gem_exec_nop -
the parallel, multi-engine workloads are more than sufficient to hog the
CPU, preventing the system from even processing ICMP echo replies.
v2: Tvrtko dug into cond_resched() on x86 and found that it only
depended upon preempt_count and not tif_need_resched() - which means
that we would always call schedule() at that point.
Fixes: c81d46138dchris@chris-wilson.co.uk >
Cc: Mika Kuoppala <mika.kuoppala@intel.com >
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Link: http://patchwork.freedesktop.org/patch/msgid/20170404120531.10737-1-chris@chris-wilson.co.uk
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
(cherry picked from commit a7980a640cjani.nikula@intel.com >
2017-04-26 16:27:58 +03:00
Chris Wilson
1676a2b35c
drm/i915: Park the signaler before sleeping
...
If the signal to park arrives before we sleep, then we need to check
kthread_should_park() before sleeping to avoid missing the signal.
Otherwise, if the signal arrives whilst we are processing completed
requests, we will reset the current->state back to TASK_INTERRUPTIBLE
and so miss the wakeup.
Fixes: fe3288b5dachris@chris-wilson.co.uk >
Cc: Mika Kuoppala <mika.kuoppala@intel.com >
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Link: http://patchwork.freedesktop.org/patch/msgid/20170403105124.8969-1-chris@chris-wilson.co.uk
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
(cherry picked from commit b1becb8826jani.nikula@intel.com >
2017-04-26 16:27:52 +03:00
Chris Wilson
f7b02a529a
drm/i915: Skip waking the signaler when enabling before request submission
...
If we are enabling the breadcrumbs signaling prior to submitting the
request, we know that we cannot have missed the interrupt and can
therefore skip immediately waking the signaler to check.
This reduces a significant chunk of the __i915_gem_request_submit()
overhead for inter-engine synchronisation, for example in gem_exec_whisper.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Link: http://patchwork.freedesktop.org/patch/msgid/20170426080659.28771-1-chris@chris-wilson.co.uk
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
2017-04-26 11:51:31 +01:00
Jani Nikula
f8a77153b0
Merge tag 'gvt-next-fixes-2017-04-20' of https://github.com/01org/gvt-linux into drm-intel-next-fixes
...
gvt-next-fixes-2017-04-20
- some code optimization from Changbin
- debug message cleanup after QoS merge
- misc fixes for display mmio init, reset vgpu warning, etc.
Signed-off-by: Jani Nikula <jani.nikula@intel.com >
2017-04-26 12:20:02 +03:00
Chris Wilson
0100186386
drm/i915: Poison the request before emitting commands
...
If we poison the request before we emit commands, it should be easier to
spot when we execute an uninitialised request.
References: https://bugs.freedesktop.org/show_bug.cgi?id=100144
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Link: http://patchwork.freedesktop.org/patch/msgid/20170423170619.7156-2-chris@chris-wilson.co.uk
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com >
2017-04-25 15:34:24 +01:00
Chris Wilson
e6ba9992de
drm/i915: Differentiate between sw write location into ring and last hw read
...
We need to keep track of the last location we ask the hw to read up to
(RING_TAIL) separately from our last write location into the ring, so
that in the event of a GPU reset we do not tell the HW to proceed into
a partially written request (which can happen if that request is waiting
for an external signal before being executed).
v2: Refactor intel_ring_reset() (Mika)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100144
Testcase: igt/gem_exec_fence/await-hang
Fixes: 821ed7df6ed55ac5bf97chris@chris-wilson.co.uk >
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Cc: Mika Kuoppala <mika.kuoppala@intel.com >
Link: http://patchwork.freedesktop.org/patch/msgid/20170425130049.26147-1-chris@chris-wilson.co.uk
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com >
2017-04-25 15:33:22 +01:00
Chris Wilson
6b764a594f
drm/i915: Report request restarts for both execlists/guc
...
As we now share the execlist_port[] tracking for both execlists/guc, we
can reset the inflight count on both and report which requests are being
restarted.
Suggested-by: Michel Thierry <michel.thierry@intel.com >
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Cc: Michel Thierry <michel.thierry@intel.com >
Cc: Mika Kuoppala <mika.kuoppala@intel.com >
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Link: http://patchwork.freedesktop.org/patch/msgid/20170425103835.31871-1-chris@chris-wilson.co.uk
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
2017-04-25 14:02:36 +01:00
Chris Wilson
695eaa3b60
drm/i915: Include interesting seqno in the missed breadcrumb debug
...
Knowing the neighbouring seqno (current on hw, last submitted to hw)
provide some useful breadcrumbs to the debug log.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Link: http://patchwork.freedesktop.org/patch/msgid/20170423170619.7156-4-chris@chris-wilson.co.uk
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com >
2017-04-24 15:53:30 +01:00
Chris Wilson
ade0b0c965
drm/i915: Confirm the request is still active before adding it to the await
...
Although we do check the completion-status of the request before
actually adding a wait on it (either to its submit fence or its
completion dma-fence), we currently do not check before adding it to the
dependency lists.
In fact, without checking for a completed request we may try to use the
signaler after it has been retired and its dependency tree freed:
[ 60.044057] BUG: KASAN: use-after-free in __list_add_valid+0x1d/0xd0 at addr ffff880348c9e6a0
[ 60.044118] Read of size 8 by task gem_exec_fence/530
[ 60.044164] CPU: 1 PID: 530 Comm: gem_exec_fence Tainted: G E 4.11.0-rc7+ #46
[ 60.044226] Hardware name: ��������������������������������� ���������������������������������/���������������������������������, BIOS RYBDWi35.86A.0246.2
[ 60.044290] Call Trace:
[ 60.044337] dump_stack+0x4d/0x6a
[ 60.044383] kasan_object_err+0x21/0x70
[ 60.044435] kasan_report+0x225/0x4e0
[ 60.044488] ? __list_add_valid+0x1d/0xd0
[ 60.044534] ? kasan_kmalloc+0xad/0xe0
[ 60.044587] __asan_load8+0x5e/0x70
[ 60.044639] __list_add_valid+0x1d/0xd0
[ 60.044788] __i915_priotree_add_dependency+0x67/0x130 [i915]
[ 60.044895] i915_gem_request_await_request+0xa8/0x370 [i915]
[ 60.044974] i915_gem_request_await_dma_fence+0x129/0x140 [i915]
[ 60.045049] i915_gem_do_execbuffer.isra.37+0xb0a/0x26b0 [i915]
[ 60.045077] ? save_stack+0xb1/0xd0
[ 60.045105] ? save_stack_trace+0x1b/0x20
[ 60.045132] ? save_stack+0x46/0xd0
[ 60.045158] ? kasan_kmalloc+0xad/0xe0
[ 60.045184] ? __kmalloc+0xd8/0x670
[ 60.045229] ? drm_ioctl+0x359/0x640 [drm]
[ 60.045256] ? SyS_ioctl+0x41/0x70
[ 60.045330] ? i915_vma_move_to_active+0x540/0x540 [i915]
[ 60.045360] ? tty_insert_flip_string_flags+0xa1/0xf0
[ 60.045387] ? tty_flip_buffer_push+0x63/0x70
[ 60.045414] ? remove_wait_queue+0xa9/0xc0
[ 60.045441] ? kasan_unpoison_shadow+0x35/0x50
[ 60.045467] ? kasan_kmalloc+0xad/0xe0
[ 60.045494] ? kasan_check_write+0x14/0x20
[ 60.045568] i915_gem_execbuffer2+0xdb/0x2a0 [i915]
[ 60.045616] drm_ioctl+0x359/0x640 [drm]
[ 60.045705] ? i915_gem_execbuffer+0x5a0/0x5a0 [i915]
[ 60.045751] ? drm_version+0x150/0x150 [drm]
[ 60.045778] ? compat_start_thread+0x60/0x60
[ 60.045805] ? plist_del+0xda/0x1a0
[ 60.045833] do_vfs_ioctl+0x12e/0x910
[ 60.045860] ? ioctl_preallocate+0x130/0x130
[ 60.045886] ? pci_mmcfg_check_reserved+0xc0/0xc0
[ 60.045913] ? vfs_write+0x196/0x240
[ 60.045939] ? __fget_light+0xa7/0xc0
[ 60.045965] SyS_ioctl+0x41/0x70
[ 60.045991] entry_SYSCALL_64_fastpath+0x17/0x98
[ 60.046017] RIP: 0033:0x7feb2baefc47
[ 60.046042] RSP: 002b:00007fff56d28e58 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
[ 60.046075] RAX: ffffffffffffffda RBX: 00007fff56d290a8 RCX: 00007feb2baefc47
[ 60.046102] RDX: 00007fff56d29050 RSI: 00000000c0406469 RDI: 0000000000000003
[ 60.046129] RBP: 00007fff56d29050 R08: 000055ecc4cd27d0 R09: 00007feb2bda8600
[ 60.046154] R10: 0000000000000073 R11: 0000000000000246 R12: 00000000c0406469
[ 60.046177] R13: 0000000000000003 R14: 000000000000000f R15: 0000000000000099
[ 60.046203] Object at ffff880348c9e680, in cache i915_dependency size: 64
[ 60.046225] Allocated:
[ 60.046246] PID = 530
[ 60.046269] save_stack_trace+0x1b/0x20
[ 60.046292] save_stack+0x46/0xd0
[ 60.046318] kasan_kmalloc+0xad/0xe0
[ 60.046343] kasan_slab_alloc+0x12/0x20
[ 60.046368] kmem_cache_alloc+0xab/0x650
[ 60.046445] i915_gem_request_await_request+0x88/0x370 [i915]
[ 60.046559] i915_gem_request_await_dma_fence+0x129/0x140 [i915]
[ 60.046705] i915_gem_do_execbuffer.isra.37+0xb0a/0x26b0 [i915]
[ 60.046849] i915_gem_execbuffer2+0xdb/0x2a0 [i915]
[ 60.046936] drm_ioctl+0x359/0x640 [drm]
[ 60.046987] do_vfs_ioctl+0x12e/0x910
[ 60.047038] SyS_ioctl+0x41/0x70
[ 60.047090] entry_SYSCALL_64_fastpath+0x17/0x98
[ 60.047139] Freed:
[ 60.047179] PID = 530
[ 60.047223] save_stack_trace+0x1b/0x20
[ 60.047269] save_stack+0x46/0xd0
[ 60.047317] kasan_slab_free+0x72/0xc0
[ 60.047366] kmem_cache_free+0x39/0x160
[ 60.047512] i915_gem_request_retire+0x83f/0x930 [i915]
[ 60.047657] i915_gem_request_alloc+0x166/0x600 [i915]
[ 60.047799] i915_gem_do_execbuffer.isra.37+0xad8/0x26b0 [i915]
[ 60.047897] i915_gem_execbuffer2+0xdb/0x2a0 [i915]
[ 60.047942] drm_ioctl+0x359/0x640 [drm]
[ 60.047968] do_vfs_ioctl+0x12e/0x910
[ 60.047993] SyS_ioctl+0x41/0x70
[ 60.048019] entry_SYSCALL_64_fastpath+0x17/0x98
[ 60.048044] Memory state around the buggy address:
[ 60.048066] ffff880348c9e580: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc
[ 60.048105] ffff880348c9e600: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc
[ 60.048138] >ffff880348c9e680: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
[ 60.048170] ^
[ 60.048191] ffff880348c9e700: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc
[ 60.048225] ffff880348c9e780: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc
Note to hit the use-after-free requires us to be passed back a request
via a fence-array, that is from explicit fencing accumulated into a
sync-file fence-array.
Fixes: 52e5420907chris@chris-wilson.co.uk >
Reviewed-by: Michał Winiarski <michal.winiarski@intel.com >
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com >
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Link: http://patchwork.freedesktop.org/patch/msgid/20170422081537.6468-1-chris@chris-wilson.co.uk
2017-04-22 09:47:44 +01:00
Chris Wilson
3dd14c04d7
drm/i915: Avoid busy-spinning on VLV_GLTC_PW_STATUS mmio
...
The busy-spin, as the first stage of intel_wait_for_register(), is
currently under suspicion for causing:
[ 62.034926] NMI watchdog: Watchdog detected hard LOCKUP on cpu 1
[ 62.034928] Modules linked in: i2c_dev i915 intel_gtt drm_kms_helper prime_numbers
[ 62.034932] CPU: 1 PID: 183 Comm: kworker/1:2 Not tainted 4.11.0-rc7+ #471
[ 62.034933] Hardware name: / , BIOS PYBSWCEL.86A.0027.2015.0507.1758 05/07/2015
[ 62.034934] Workqueue: pm pm_runtime_work
[ 62.034936] task: ffff880275a04ec0 task.stack: ffffc900002d8000
[ 62.034936] RIP: 0010:__intel_wait_for_register_fw+0x77/0x1a0 [i915]
[ 62.034937] RSP: 0018:ffffc900002dbc38 EFLAGS: 00000082
[ 62.034939] RAX: ffffc90003530094 RBX: 0000000000130094 RCX: 0000000000000001
[ 62.034940] RDX: 00000000000000a1 RSI: ffff88027fd15e58 RDI: 0000000000000000
[ 62.034941] RBP: ffffc900002dbc78 R08: 0000000000000002 R09: 0000000000000000
[ 62.034942] R10: ffffc900002dbc18 R11: ffff880276429dd0 R12: ffff8802707c0000
[ 62.034943] R13: 00000000000000a0 R14: 0000000000000000 R15: 00000000fffefc10
[ 62.034945] FS: 0000000000000000(0000) GS:ffff88027fd00000(0000) knlGS:0000000000000000
[ 62.034945] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 62.034947] CR2: 00007ffd3cd98ff8 CR3: 0000000274c19000 CR4: 00000000001006e0
[ 62.034947] Call Trace:
[ 62.034948] intel_wait_for_register+0x77/0x140 [i915]
[ 62.034949] vlv_suspend_complete+0x23/0x5b0 [i915]
[ 62.034950] intel_runtime_suspend+0x16c/0x2a0 [i915]
[ 62.034950] pci_pm_runtime_suspend+0x50/0x180
[ 62.034951] ? pci_pm_runtime_resume+0xa0/0xa0
[ 62.034952] __rpm_callback+0xc5/0x210
[ 62.034953] rpm_callback+0x1f/0x80
[ 62.034953] ? pci_pm_runtime_resume+0xa0/0xa0
[ 62.034954] rpm_suspend+0x118/0x580
[ 62.034955] pm_runtime_work+0x64/0x90
[ 62.034956] process_one_work+0x1bb/0x3e0
[ 62.034956] worker_thread+0x46/0x4f0
[ 62.034957] ? __schedule+0x18b/0x610
[ 62.034958] kthread+0xff/0x140
[ 62.034958] ? process_one_work+0x3e0/0x3e0
[ 62.034959] ? kthread_create_on_node+
and related hard lockups in CI for byt and bsw.
Note this effectively reverts commits 41ce405e68b27366958841ce405e68b273669588https://bugs.freedesktop.org/show_bug.cgi?id=100718
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com >
Cc: Tomi Sarvela <tomi.p.sarvela@intel.com >
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Link: http://patchwork.freedesktop.org/patch/msgid/20170421135815.11897-1-chris@chris-wilson.co.uk
Tested-by: Tomi Sarvela <tomi.p.sarvela@intel.com >
2017-04-21 16:40:09 +01:00
Chris Wilson
546cdbc75b
drm/i915: Stop touching hangcheck.seqno from intel_engine_init_global_seqno()
...
The hangcheck runs independently to the main flow of seqno through the
driver. However, we have an odd coupling of the seqno reset that is
unwelcome, and if poked at just the right rate can cause spurious hangs
(e.g. gem_exec_whisper) on an apparently idle engine.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com >
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com >
Link: http://patchwork.freedesktop.org/patch/msgid/20170421083113.21321-1-chris@chris-wilson.co.uk
2017-04-21 09:58:24 +01:00
Dave Airlie
6b1462700b
Merge tag 'drm-misc-next-fixes-2017-04-20' of git://anongit.freedesktop.org/git/drm-misc into drm-next
...
drm-misc-next-fixes-2017-04-20
Core changes:
- Maintain sti via drm-misc (Vincent)
- Rename dma_buf_ops->kmap_* to avoid naming collision (Logan)
Driver changes:
- Fix UHD displays on stih407 (Vincent)
- Fix uninitialized var return in atmel-hlcdc (Dan)
* tag 'drm-misc-next-fixes-2017-04-20' of git://anongit.freedesktop.org/git/drm-misc:
dma-buf: Rename dma-ops to prevent conflict with kunmap_atomic macro
drm: atmel-hlcdc: Uninitialized return in atmel_hlcdc_create_outputs()
drm/sti: fix GDP size to support up to UHD resolution
MAINTAINERS: add drm/sti driver into drm-misc
2017-04-21 13:51:59 +10:00
Chris Wilson
2d6c4c8423
drm/i915: Use discardable buffers for rings
...
The contents of a ring are only valid between HEAD and TAIL, when the
ring is idle (HEAD == TAIL) we can simply let the pages go under memory
pressure if they are not pinned by an active context. Any new content
will be written after HEAD and so the ring will again be valid between
HEAD and TAIL, everything outside can be discarded.
Note that we take care of ensuring that we do not reset the HEAD
backwards following a GPU hang on an idle ring.
The same precautions are what enable us to use stolen memory for rings.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Link: http://patchwork.freedesktop.org/patch/msgid/20170420101709.27250-1-chris@chris-wilson.co.uk
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com >
2017-04-20 12:00:32 +01:00
Chris Wilson
2310b3c952
drm/i915/selftests: Allocate inode/file dynamically
...
Avoid having too large a stack by creating the fake struct inode/file on
the heap instead.
drivers/gpu/drm/i915/selftests/mock_drm.c: In function 'mock_file':
drivers/gpu/drm/i915/selftests/mock_drm.c:46:1: error: the frame size of 1328 bytes is larger than 1280 bytes [-Werror=frame-larger-than=]
drivers/gpu/drm/i915/selftests/mock_drm.c: In function 'mock_file_free':
drivers/gpu/drm/i915/selftests/mock_drm.c:54:1: error: the frame size of 1312 bytes is larger than 1280 bytes [-Werror=frame-larger-than=]
Reported-by: Arnd Bergmann <arnd@arndb.de >
Fixes: 66d9cb5d80chris@chris-wilson.co.uk >
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com >
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Cc: Matthew Auld <matthew.auld@intel.com >
Cc: Arnd Bergmann <arnd@arndb.de >
Acked-by: Arnd Bergmann <arnd@arndb.de >
Link: http://patchwork.freedesktop.org/patch/msgid/20170419094143.16922-2-chris@chris-wilson.co.uk
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com >
2017-04-20 09:33:46 +01:00
Logan Gunthorpe
f9b67f0014
dma-buf: Rename dma-ops to prevent conflict with kunmap_atomic macro
...
Seeing the kunmap_atomic dma_buf_ops share the same name with a macro
in highmem.h, the former can be aliased if any dma-buf user includes
that header.
I'm personally trying to include highmem.h inside scatterlist.h and this
breaks the dma-buf code proper.
Christoph Hellwig suggested [1] renaming it and pushing this patch ASAP.
To maintain consistency I've renamed all four of kmap* and kunmap* to be
map* and unmap*. (Even though only kmap_atomic presently conflicts.)
[1] https://www.spinics.net/lists/target-devel/msg15070.html
Signed-off-by: Logan Gunthorpe <logang@deltatee.com >
Reviewed-by: Sinclair Yeh <syeh@vmware.com >
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch >
Acked-by: Sumit Semwal <sumit.semwal@linaro.org >
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org >
Link: http://patchwork.freedesktop.org/patch/msgid/1492630570-879-1-git-send-email-logang@deltatee.com
2017-04-20 13:47:46 +05:30
Kees Cook
916a491d11
drm/i915: Avoid format string expansion from engine names
...
While highly unlikely, this makes sure that the string built from
engine names won't be processed as a format string.
Signed-off-by: Kees Cook <keescook@chromium.org >
Signed-off-by: Jani Nikula <jani.nikula@intel.com >
Link: http://patchwork.freedesktop.org/patch/msgid/20170411045630.GA6612@beast
2017-04-19 15:49:27 +03:00
Tvrtko Ursulin
939cf46c3a
drm/i915: Fix GCC 4.4 build issue with __intel_wait_for_register_fw
...
Move the BUILD_BUG_ONs for busy-wait duration outside the
_wait_for_atomic macro as discussed on the mailing list.
v2: Simplify the macro by omitting the ret__ local. (Chris Wilson)
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Suggested-by: Michal Wajdeczko <michal.wajdeczko@intel.com >
Fixes: 1d1a9774e4michal.wajdeczko@intel.com >
Cc: Chris Wilson <chris@chris-wilson.co.uk >
Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com >
Link: http://patchwork.freedesktop.org/patch/msgid/20170418105211.7089-1-tvrtko.ursulin@linux.intel.com
2017-04-19 12:29:09 +01:00
Dave Airlie
856ee92e86
Merge tag 'v4.11-rc7' into drm-next
...
Backmerge Linux 4.11-rc7 from Linus tree, to fix some
conflicts that were causing problems with the rerere cache
in drm-tip.
2017-04-19 11:07:14 +10:00
Mika Kuoppala
3396a27385
drm/i915: Fix system hang with EI UP masked on Haswell
...
Previously with commit a9c1f90c8ehttps://bugs.freedesktop.org/show_bug.cgi?id=100672
Cc: Chris Wilson <chris@chris-wilson.co.uk >
Cc: stable@vger.kernel.org
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com >
Acked-by: Chris Wilson <chris@chris-wilson.co.uk >
Link: http://patchwork.freedesktop.org/patch/msgid/1492082127-29007-1-git-send-email-mika.kuoppala@intel.com
2017-04-18 15:09:59 +03:00
Dan Carpenter
c821ee6d2b
drm/i915/gvt: fix a bounds check in ring_id_to_context_switch_event()
...
There are two bugs here. The && should be || and the > is off by one so
it should be >= ARRAY_SIZE().
Fixes: 8453d674aedan.carpenter@oracle.com >
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com >
2017-04-18 17:50:05 +08:00
Daniel Vetter
a0242b0d59
drm/i915: Update DRIVER_DATE to 20170418
...
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch >
2017-04-18 11:18:16 +02:00
