- 03 May, 2017 6 commits
-
-
Chris Wilson authored
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
-
Chris Wilson authored
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:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170503093924.5320-3-chris@chris-wilson.co.uk
-
Chris Wilson authored
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 authored
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:
-
Mika Kuoppala authored
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=100247Signed-off-by:
Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by:
-
Mika Kuoppala authored
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:
-
- 02 May, 2017 3 commits
-
-
Michal Wajdeczko authored
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:
-
Joonas Lahtinen authored
Add intel_irq_fini() for placing the deinitialization code, starting with freeing dev_priv->l3_parity.remap_info[]. Signed-off-by:
-
Daniel Vetter authored
Signed-off-by:Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 28 Apr, 2017 6 commits
-
-
Ander Conselvan de Oliveira authored
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: 46448483 ("drm/i915/glk: Add MIPIIO Enable/disable sequence") Cc: Deepak M <m.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
-
Joonas Lahtinen authored
CCID register existed already on ILK according to the PRM (Chris verified the address to match too). Signed-off-by:
-
Joonas Lahtinen authored
ILK should survive a reset without display corruption. Suggested-by:
-
Joonas Lahtinen authored
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 authored
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:
-
Tvrtko Ursulin authored
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:
Michel Thierry <michel.thierry@intel.com> Reviewed-by:
-
- 27 Apr, 2017 3 commits
-
-
Chris Wilson authored
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:
-
Michel Thierry authored
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 authored
It has been replaced by I915_RESET_BACKOFF / I915_RESET_HANDOFF. Signed-off-by:
-
- 26 Apr, 2017 2 commits
-
-
Ander Conselvan de Oliveira authored
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:
Shashank Sharma <shashank.sharma@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170424104718.26448-1-ander.conselvan.de.oliveira@intel.com
-
Chris Wilson authored
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:
-
- 25 Apr, 2017 3 commits
-
-
Chris Wilson authored
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=100144Signed-off-by:
-
Chris Wilson authored
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: 821ed7df ("drm/i915: Update reset path to fix incomplete requests") Fixes: d55ac5bf ("drm/i915: Defer transfer onto execution timeline to actual hw submission") Signed-off-by:
-
Chris Wilson authored
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:
-
- 24 Apr, 2017 1 commit
-
-
Chris Wilson authored
Knowing the neighbouring seqno (current on hw, last submitted to hw) provide some useful breadcrumbs to the debug log. Signed-off-by:
-
- 22 Apr, 2017 1 commit
-
-
Chris Wilson authored
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: 52e54209 ("drm/i915/scheduler: Record all dependencies upon request construction") Testcase: igt/gem_exec_fence/expired-history Signed-off-by:
Michał Winiarski <michal.winiarski@intel.com> Reviewed-by:
-
- 21 Apr, 2017 2 commits
-
-
Chris Wilson authored
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 41ce405e and b2736695 ("drm/i915: Convert wait_for(I915_READ(reg)) to intel_wait_for_register()") v2: Convert bool allow into a u32 mask for clarity and repeat the comment on vlv rc6 timing to justify the 3ms timeout used for the wait (Ville) Fixes: 41ce405e ("drm/i915: Convert wait_for(I915_READ(reg)) to intel_wait_for_register()") Fixes: b2736695 ("drm/i915: Convert wait_for(I915_READ(reg)) to intel_wait_for_register()") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100718Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170421135815.11897-1-chris@chris-wilson.co.ukTested-by:
Tomi Sarvela <tomi.p.sarvela@intel.com>
-
Chris Wilson authored
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:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170421083113.21321-1-chris@chris-wilson.co.uk
-
- 20 Apr, 2017 2 commits
-
-
Chris Wilson authored
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 authored
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: 66d9cb5d ("drm/i915: Mock the GEM device for self-testing") Signed-off-by:
-
- 19 Apr, 2017 2 commits
-
-
Kees Cook authored
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
-
Tvrtko Ursulin authored
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:
-
- 18 Apr, 2017 2 commits
-
-
Mika Kuoppala authored
Previously with commit a9c1f90c ("drm/i915: Don't mask EI UP interrupt on IVB|SNB") certain, seemingly unrelated bit (GEN6_PM_RP_UP_EI_EXPIRED) was needed to be unmasked for IVB and SNB in order to prevent system hang with chained batchbuffers. Our CI was seeing incomplete results with tests that used chained batches and it was found out that HSW needs to have this same bit unmasked to reliably survive chained batches. Always unmask GEN6_PM_RP_UP_EI_EXPIRED on Haswell to prevent system hang with batch chaining. Testcase: igt/gem_exec_fence/nb-await-default Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100672 Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: stable@vger.kernel.org Signed-off-by:
-
Daniel Vetter authored
Signed-off-by:
-
- 15 Apr, 2017 2 commits
-
-
Chris Wilson authored
Introduce a new execobject.flag (EXEC_OBJECT_CAPTURE) that userspace may use to indicate that it wants the contents of this buffer preserved in the error state (/sys/class/drm/cardN/error) following a GPU hang involving this batch. Use this at your discretion, the contents of the error state. although compressed, are allocated with GFP_ATOMIC (i.e. limited) and kept for all eternity (until the error state is destroyed). Based on an earlier patch by Ben Widawsky <ben@bwidawsk.net> Testcase: igt/gem_exec_capture Signed-off-by:
Ben Widawsky <ben@bwidawsk.net> Acked-by:
Matt Turner <mattst88@gmail.com> Reviewed-by:
-
Dan Carpenter authored
If "crtc" is NULL, then my static checker complains that "ret" isn't initialized on that path. It doesn't really cause a problem unless "ret" is somehow set to -EDEADLK which is not likely. Chris Wilson also noticed another error path where "ret" isn't set correctly. Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170414195425.GA8144@mwandaReviewed-by:
-
- 13 Apr, 2017 4 commits
-
-
Dan Carpenter authored
i915_gem_request_alloc() uses error pointers. It never returns NULLs. Fixes: 0daf0113 ("drm/i915: Mock infrastructure for request emission") Signed-off-by:
-
Manasi Navare authored
If link training at a link rate optimal for a particular mode fails during modeset's atomic commit phase, then we let the modeset complete and then retry. We save the link rate value at which link training failed, update the link status property to "BAD" and use a lower link rate to prune the modes. It will redo the modeset on the current mode at lower link rate or if the current mode gets pruned due to lower link constraints then, it will send a hotplug uevent for userspace to handle it. This is also required to pass DP CTS tests 4.3.1.3, 4.3.1.4, 4.3.1.6. This patch is a resend of the original commit id (233ce881 "drm/i915: Implement Link Rate fallback on Link training failure") which got reverted in this commit id (afc1ebf4 Revert "drm/i915: Implement Link Rate fallback on Link training failure") due to CI failures. After investigating the CI failures it was found that these were essentially the failures which were always there but hidden because they used to be DRM_DEBUG_KMS messages for link failures so never got caught by CI. But now this patch actually throws DRM_ERROR if the link training fails at RBR and 1 lane. So it caught these link train failures. There were two failures: 1. On SKL 6700k this was because the machine in CI lab is a SKL desktop without eDP on Port A. But our VBT initialization code in the driver writes VBT defaults in a way that it always sets DP flag on Port A and this does not get cleared after parsing the VBT outputs. This has been fixed in commit id (bb1d1329 "drm/i915/vbt: split out defaults that are set when there is no VBT) and (66578857 "drm/i915/vbt: don't propagate errors from intel_bios_init()) 2. On ILK-650 desktop - This was happening because of a bad monitor desktop combination. I switched the monitor in the CI lab and that helped get rid of the link failures on ILK system. v10: * Rebase on drm-tip and resend after revert v9: * Use the trimmed max values of link rate/lane count based on link train fallback (Daniel Vetter) v8: * Set link_status to BAD first and then call mode_valid (Jani Nikula) v7: Remove the redundant variable in previous patch itself v6: * Obtain link rate index from fallback_link_rate using the helper intel_dp_link_rate_index (Jani Nikula) * Include fallback within intel_dp_start_link_train (Jani Nikula) v5: * Move set link status to drm core (Daniel Vetter, Jani Nikula) v4: * Add fallback support for non DDI platforms too * Set connector->link status inside set_link_status function (Jani Nikula) v3: * Set link status property to BAd unconditionally (Jani Nikula) * Dont use two separate variables link_train_failed and link_status to indicate same thing (Jani Nikula) v2: * Squashed a few patches (Jani Nikula) Acked-by:
Tony Cheng <tony.cheng@amd.com> Acked-by:
Harry Wentland <Harry.wentland@amd.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Signed-off-by:
Manasi Navare <manasi.d.navare@intel.com> Reviewed-by:
-
Ville Syrjälä authored
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 7d23e3c3 ("drm/i915: Cleaning up intel_dp_hpd_pulse"). I'm actually not sure why that was there. Perhaps to avoid an EDID read if the connector status didn't appear to change, but that sort of thing is quite racy and would have failed anyway if we failed to keep up with the hotplugs (if we missed the HPD down in between two HPD ups). And now that we take this codepath unconditionally we definitely need to drop the goto as otherwise we would never do the EDID read. v2: Drop the goto that made us skip EDID reads entirely. Doh! v3: Rebase due to locking changes s/apparely/apparently/ in the comment (Chris) Cc: stable@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.htmlSigned-off-by:
-
daniele.ceraolospurio@intel.com authored
The wopcm registers are write-once, so any write after the first one will just be ignored. The registers survive a GPU reset but not always a suspend/resume cycle, so to keep things simple keep the writes in the intel_uc_init_hw function instead of moving it earlier to make sure we attempt them every time we try to load GuC. Cc: Jeff McGee <jeff.mcgee@intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Signed-off-by:
-
- 12 Apr, 2017 1 commit
-
-
Chris Wilson authored
[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: eef57324 ("drm/i915: setup bridge for HDMI LPE audio driver") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99952Signed-off-by:
Takashi Iwai <tiwai@suse.de> Reviewed-by:
-
