- 19 Jan, 2018 6 commits
-
-
Ville Syrjälä authored
Split the g4x and snb cases into separate functions to match how we deal with all other platforms. Also sort the switch cases to match the format lists we've declared earlier, to ease comparisons. Cc: Ben Widawsky <ben@bwidawsk.net> Cc: Jason Ekstrand <jason@jlekstrand.net> Cc: Daniel Stone <daniels@collabora.com> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171222192231.17981-5-ville.syrjala@linux.intel.comReviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
Y/Yf were dropped out from the SKL+ sprite modifier list on account of some watermark issues Daniel Stone was having. My subsequent testing seemed to indicate that things work better now, so add the modifiers back in. v2: Update the commit message with a better explanation Cc: Ben Widawsky <ben@bwidawsk.net> Cc: Jason Ekstrand <jason@jlekstrand.net> Cc: Daniel Stone <daniels@collabora.com> Signed-off-by:
-
Ville Syrjälä authored
The unreachable() is very much unreachable and the compiler knows that, so there's no point in having it. Cc: Ben Widawsky <ben@bwidawsk.net> Cc: Jason Ekstrand <jason@jlekstrand.net> Cc: Daniel Stone <daniels@collabora.com> Signed-off-by:
-
Abdiel Janulgue authored
4K modes testing by using dummy EDID data has never been working properly on boxes with DP++ (dual-mode) adaptors. The reason for this is that those modes got pruned during hdmi mode validation. intel_hdmi_mode_valid returns CLOCK_HIGH because the pixel clock reported by the 4k mode is higher than dual port TMDS clock limit. However 4k injection does work properly on machines that don't have DP++ adapters because the mode is never validated against the DP++ TMDS clock limit. v2: Don't detect the DP++ limits when we're testing using overridden EDIDs. Make sure to check for the override condition after respecting the value of drm_dp_dual_mode_detect (Jani Nikula). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101649 Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:Abdiel Janulgue <abdiel.janulgue@linux.intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171215102055.11729-1-abdiel.janulgue@linux.intel.com
-
Jani Nikula authored
drm_edid_to_eld() sets ELD connector type since commit 1d1c3665 ("drm/edid: set ELD connector type in drm_edid_to_eld()"). Remove the redundant update. (Commit c945b8c1 ("drm/edid: build ELD in drm_add_edid_modes()") and commit d471ed04 ("drm/drivers: drop redundant drm_edid_to_eld() calls") are also related.) v2: Rebase, update commit message with commit references. Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Acked-by:
Thierry Reding <treding@nvidia.com> Signed-off-by:
-
Jani Nikula authored
No more sing-a-ling. Reported-by:
Adam Jackson <ajax@redhat.com> You're-my-ding-a-ling-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
David Weinehall <david.weinehall@linux.intel.com> Signed-off-by:
-
- 18 Jan, 2018 8 commits
-
-
Jani Nikula authored
Update VBT defs to reflect revision 216. While at it, default the expected child device struct size to sizeof the size rather than a hardcoded value. v2: Fix bit order (David) Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Lucas De Marchi authored
Display WA #1178 is meant to fix Aux channel voltage swing too low with some type C dongles. Although it is for type C, HW engineers reported that it can be applied to all external ports even if they are not going to type C. For CNL we apply the workaround every time Aux B, C and D are powering up since they will lose the configuration when powered down. v2: Use common tag for WA Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Arthur J Runyan <arthur.j.runyan@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
-
Michel Thierry authored
Instead of using local string names that we will have to keep maintaining, use the engine->name directly. v2: Better invalid engine_id handling, capture_bo will not be able know the engine_id and end up with -1 (Michal). Suggested-by:
Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by:
Michel Thierry <michel.thierry@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180110012151.28261-1-michel.thierry@intel.com [ickle: minor massaging of function names] Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180118175228.2830-1-chris@chris-wilson.co.uk
-
Michal Wajdeczko authored
Today we have format mismatch between read/write operations of i915_guc_log_control entry. For read we return (0, 1..4) that represents disable/verbosity levels, but for write we force user to follow internal structure format (0,1,9,11,13). Let's hide internals from the user and accept same values as we support for read and related guc_log_level modparam. Signed-off-by:
Sagar Arun Kamble <sagar.a.kamble@intel.com> Signed-off-by:
-
Michal Wajdeczko authored
We used value -1 to indicate "disabled" and values 0..3 to indicate "enabled", but most of our other modparams are using -1 for "auto" mode and 0 for "disable". For consistency let's change our log level values to: -1: auto (depends on platform and Kconfig.debug settings) 0: disabled 1: enabled (severity level 0 = min) 2: enabled (severity level 1) 3: enabled (severity level 2) 4: enabled (severity level 3 = max) v2: fix commit message (Sagar) display sanitized modparam value (Sagar) unify sanitize messages (Sagar/Michal) Signed-off-by: -
Chris Wilson authored
Watching a light workload on Baytrail (running glxgears and a 1080p decode), instead of the system remaining at low frequency, the glxgears would regularly trigger waitboosting after which it would have to spend a few seconds throttling back down. In this case, the waitboosting is counter productive as the minimal wait for glxgears doesn't prevent it from functioning correctly and delivering frames on time. In this case, glxgears happens to almost always be waiting on the current request, which we already expect to complete quickly (see i915_spin_request) and so avoiding the waitboost on the active request and spinning instead provides the best latency without overcommitting to upclocking. However, if the system falls behind we still force the waitboost. Similarly, we will also trigger upclocking if we detect the system is not delivering frames on time - again using a mechanism that tries to detect a miss and not preemptively upclock. v2: Also skip boosting for after missed vblank if the desired request is already active. Signed-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180118131609.16574-1-chris@chris-wilson.co.uk
-
Imre Deak authored
The CDCLK bypass frequency can vary on upcoming platforms, so prepare for that now by tracking its value in the CDCLK state. Currently on BDW+ the bypass frequency is always the reference clock and I didn't bother with earlier platforms since it's not all that clear what's the bypass clock on those. I also didn't bother adding support for changing this frequency, since atm I don't see any need for it. Suggested-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
-
Chris Wilson authored
Since commit 4e773c3a ("drm/i915: Wire up shrinkctl->nr_scanned"), we track the number of objects we scan and do not wish to exceed that as it will overly penalise our own slabs under mempressure. Given that we now know the target number of objects to scan, use that as our guide for deciding to shrink as opposed to the number of objects we manage to shrink (which doesn't correspond to the numbers we report to shrinkctl). Fixes: 4e773c3a ("drm/i915: Wire up shrinkctl->nr_scanned") Signed-off-by:
-
- 17 Jan, 2018 3 commits
-
-
Arnd Bergmann authored
struct timeval is deprecated because it cannot represent times past 2038. In this driver, the only use of this structure is to capture debug information. This is easily changed to ktime_t, which we then format as needed when printing it later. Reviewed-by:
Arnd Bergmann <arnd@arndb.de> Link: https://patchwork.freedesktop.org/patch/msgid/20180117154916.219273-1-arnd@arndb.deSigned-off-by:
-
Chris Wilson authored
When testing that the timeout fired, we need to be sure we have waited just long enough for the timeout to have occurred and for the softirq (on another cpu) to have completed. Sleeping for an arbitrary amount is prone to error, so wait for the timeout instead and complain if it was too late. v2: Use wait_event_timeout to provide an upper bound v3: Fix inverted check for wait_event_timeout timing out v4: Restore the check that the fences aren't signalled too early, by inspecting them before the expected timeout. References: https://bugs.freedesktop.org/show_bug.cgi?id=104670Signed-off-by:
-
Maarten Lankhorst authored
It's perfectly legal to create a fb with stride < 512, and one of the kms_plane_scaling subtests creates a very small fb. Downgrade the WARN_ON to a simple check check, and because this function is potentially called on every atomic update/pageflip, downgrade the other WARN_ON to a WARN_ON_ONCE, and do the right thing here. Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180116155331.75175-1-maarten.lankhorst@linux.intel.comReviewed-by:
-
- 16 Jan, 2018 3 commits
-
-
Maarten Lankhorst authored
intel_power_domains_init_hw() calls set_init_power, but when using runtime power management this call is skipped. This prevents hw readout from taking place. Signed-off-by:
-
Chris Wilson authored
Tvrtko noticed that the comments describing the interaction of RCU and the deferred worker for freeing drm_i915_gem_object were a little confusing, so attempt to bring some sense to them. Signed-off-by:
-
Chris Wilson authored
Check that we can successfully wait upon a dma_fence using the i915_sw_fence, including the optional timeout mechanism. v2: Account for the rounding up of the timeout to the next second. Unfortunately, the minimum delay is then 1 second. Signed-off-by:
-
- 15 Jan, 2018 4 commits
-
-
Chris Wilson authored
As freeing the objects require serialisation on struct_mutex, we should prefer to use our singlethreaded driver wq that is dedicated to work requiring struct_mutex (hence serialised).The benefit should be less clutter on the system wq, allowing it to make progress even when the driver/struct_mutex is heavily contended. Signed-off-by:
-
Chris Wilson authored
In order to prevent a race condition where we may end up overaccounting the active state and leaving the busy-stats believing the GPU is 100% busy, lock out the tasklet while we reconstruct the busy state. There is no direct spinlock guard for the execlists->port[], so we need to utilise tasklet_disable() as a synchronous barrier to prevent it, the only writer to execlists->port[], from running at the same time as the enable. Fixes: 4900727d ("drm/i915/pmu: Reconstruct active state on starting busy-stats") Signed-off-by:
-
Chris Wilson authored
As the timeout mechanism has grown more and more complicated, using multiple deferred tasks and more than doubling the size of our struct, split the two implementations to streamline the simpler no-timeout callback variant. Signed-off-by:
-
Chris Wilson authored
Without an accompanying timer (for internal fences), we can free the fence callback immediately as we do not need to employ the RCU barrier to serialise with the timer. By avoiding the RCU delay, we can avoid the extra mempressure under heavy inter-engine request utilisation. Signed-off-by:
-
- 12 Jan, 2018 5 commits
-
-
Dhinakaran Pandiyan authored
DPCD read for the eDP is complete by the time intel_psr_init() is called, which means we can avoid initializing PSR structures and state if there is no sink support. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by:
-
Dhinakaran Pandiyan authored
The global variable dev_priv->psr.sink_support is set if an eDP sink supports PSR. Use this instead of redoing the check with is_edp_psr(). Combine source and sink support checks into a macro that can be used to return early from psr_{invalidate, single_frame_update, flush}. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: -
Dhinakaran Pandiyan authored
This flag has become redundant since commit 4d90f2d5 ("drm/i915: Start tracking PSR state in crtc state") It is set at the same place as psr.enabled, which is also exposed via debugfs. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Tvrtko Ursulin authored
kcalloc is preffered for allocating arrays. Signed-off-by:
-
Fengguang Wu authored
drivers/gpu/drm/i915/i915_pmu.c:795:34-40: ERROR: application of sizeof to pointer sizeof when applied to a pointer typed expression gives the size of the pointer Generated by: scripts/coccinelle/misc/noderef.cocci Fixes: 109ec558 ("drm/i915/pmu: Only enumerate available counters in sysfs") Signed-off-by:
Fengguang Wu <fengguang.wu@intel.com> Reviewed-by:
-
- 11 Jan, 2018 4 commits
-
-
Chris Wilson authored
We have a hole in our busy-stat accounting if the pmu is enabled during a long running batch, the pmu will not start accumulating busy-time until the next context switch. This then fails tests that are only sampling a single batch. v2: Count each active port just once (context in/out events are only on the first and last assignment to a port). v3: Avoid hardcoding knowledge of 2 submission ports Fixes: 30e17b78 ("drm/i915: Engine busy time tracking") Testcase: igt/perf_pmu/busy-start Testcase: igt/perf_pmu/busy-double-start Signed-off-by:
-
Chris Wilson authored
As we kmalloc our dynamic sysfs attributes, we have to give them an external static lock_class_key for them to use with lockdep. Fixes: 109ec558 ("drm/i915/pmu: Only enumerate available counters in sysfs") Signed-off-by:
-
Tvrtko Ursulin authored
Switch over to dynamically creating device attributes, which are in turn used by the perf core to expose available counters in sysfs. This way we do not expose counters which are not avaiable on the current platform, and are so more consistent between what we reply to open attempts via the perf_event_open(2), and what is discoverable in sysfs. v2: * Simplify attribute pointer freeing loop. * Changed attr init from macro to function. * More common error unwind. (Chris Wilson) * Rename some locals. (Chris Wilson) v3: * Fixed double semi-colon. (Chris Wilson) Signed-off-by:
-
Tvrtko Ursulin authored
With firmware 1.07 having fixed the state corruption issue, we can enable the headless GT performance workaround for CNL as well. (Equivalent to b6876374 ("drm/i915: Restore GT performance in headless mode with DMC loaded") on other affected platforms.) Signed-off-by:
-
- 10 Jan, 2018 2 commits
-
-
Oscar Mateo authored
This register does not contain it. Instead, we have to look into FAULT_TLB_DATA0 & 1 (where, by the way, we can also get the address space). v2: Right formatting v3: - Use 12 (as per the register format) instead of PAGE_SIZE (Chris) - s/BITS_44_TO_47/HIGHBITS (Chris) - Right formatting, this time for real Fixes: b03ec3d6 ("drm/i915: There is only one fault register from GEN8 onwards") Signed-off-by:
Oscar Mateo <oscar.mateo@intel.com> Cc: Michel Thierry <michel.thierry@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/1513982329-32191-1-git-send-email-oscar.mateo@intel.comReviewed-by:
-
Sagar Arun Kamble authored
While moving code around for solving lockdep issue for GuC log relay, spotted that uc_fini_wq is not being called in failure path in gem_init. Missed in the below commit. Add it. v2: Removed GEM_BUG_ON(!HAS_GUC()) from intel_uc_fini_wq as init happens only based on enable_guc module parameter and does not consider has_guc capability. (Michal) Signed-off-by:
Michał Winiarski <michal.winiarski@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1515588857-10283-1-git-send-email-sagar.a.kamble@intel.comSigned-off-by:
-
- 09 Jan, 2018 2 commits
-
-
Imre Deak authored
The power domain masks are 64 bit wide, so we need BIT_ULL() when setting bits in them, these ones were missed during converting from 32 to 64 bit masks. All 3 enums are <32 atm, so this didn't cause a real problem. Fixes: d8fc70b7 ("drm/i915: Make power domain masks 64 bit long") Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reported-by:
-
Stefan Brüns authored
The ACK/NACK implementation as found in e.g. the G965 has the falling clock edge and the release of the data line after the ACK for the received byte happen at the same time. This is conformant with the I2C specification, which allows a zero hold time, see footnote [3]: "A device must internally provide a hold time of at least 300 ns for the SDA signal (with respect to the V IH(min) of the SCL signal) to bridge the undefined region of the falling edge of SCL." Some HDMI-to-VGA converters apparently fail to adhere to this requirement and latch SDA at the falling clock edge, so instead of an ACK sometimes a NACK is read and the slave (i.e. the EDID ROM) ends the transfer. The bitbanging releases the data line for the ACK only 1/4 bit time after the falling clock edge, so a slave will see the correct value no matter if it samples at the rising or the falling clock edge or in the center. Fallback to bitbanging is already done for the CRT connector. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92685Signed-off-by:
Stefan Brüns <stefan.bruens@rwth-aachen.de> Cc: stable@vger.kernel.org Signed-off-by:
-
- 08 Jan, 2018 1 commit
-
-
Chris Wilson authored
When we retire a signaled fence, we free the dependency tree. However, we skip clearing the list so that if we then try to adjust the priority of the signaled fence, we may walk the list of freed dependencies. [ 3083.156757] ================================================================== [ 3083.156806] BUG: KASAN: use-after-free in execlists_schedule+0x199/0x660 [i915] [ 3083.156810] Read of size 8 at addr ffff8806bf20f400 by task Xorg/831 [ 3083.156815] CPU: 0 PID: 831 Comm: Xorg Not tainted 4.15.0-rc6-no-psn+ #1 [ 3083.156817] Hardware name: Notebook N24_25BU/N24_25BU, BIOS 5.12 02/17/2017 [ 3083.156818] Call Trace: [ 3083.156823] dump_stack+0x5c/0x7a [ 3083.156827] print_address_description+0x6b/0x290 [ 3083.156830] kasan_report+0x28f/0x380 [ 3083.156872] ? execlists_schedule+0x199/0x660 [i915] [ 3083.156914] execlists_schedule+0x199/0x660 [i915] [ 3083.156956] ? intel_crtc_atomic_check+0x146/0x4e0 [i915] [ 3083.156997] ? execlists_submit_request+0xe0/0xe0 [i915] [ 3083.157038] ? i915_vma_misplaced.part.4+0x25/0xb0 [i915] [ 3083.157079] ? __i915_vma_do_pin+0x7c8/0xc80 [i915] [ 3083.157121] ? intel_atomic_state_alloc+0x44/0x60 [i915] [ 3083.157130] ? drm_atomic_helper_page_flip+0x3e/0xb0 [drm_kms_helper] [ 3083.157145] ? drm_mode_page_flip_ioctl+0x7d2/0x850 [drm] [ 3083.157159] ? drm_ioctl_kernel+0xa7/0xf0 [drm] [ 3083.157172] ? drm_ioctl+0x45b/0x560 [drm] [ 3083.157211] i915_gem_object_wait_priority+0x14c/0x2c0 [i915] [ 3083.157251] ? i915_gem_get_aperture_ioctl+0x150/0x150 [i915] [ 3083.157290] ? i915_vma_pin_fence+0x1d8/0x320 [i915] [ 3083.157331] ? intel_pin_and_fence_fb_obj+0x175/0x250 [i915] [ 3083.157372] ? intel_rotation_info_size+0x60/0x60 [i915] [ 3083.157413] ? intel_link_compute_m_n+0x80/0x80 [i915] [ 3083.157428] ? drm_dev_printk+0x1b0/0x1b0 [drm] [ 3083.157443] ? drm_dev_printk+0x1b0/0x1b0 [drm] [ 3083.157485] intel_prepare_plane_fb+0x2f8/0x5a0 [i915] [ 3083.157527] ? intel_crtc_get_vblank_counter+0x80/0x80 [i915] [ 3083.157536] drm_atomic_helper_prepare_planes+0xa0/0x1c0 [drm_kms_helper] [ 3083.157587] intel_atomic_commit+0x12e/0x4e0 [i915] [ 3083.157605] drm_atomic_helper_page_flip+0xa2/0xb0 [drm_kms_helper] [ 3083.157621] drm_mode_page_flip_ioctl+0x7d2/0x850 [drm] [ 3083.157638] ? drm_mode_cursor2_ioctl+0x10/0x10 [drm] [ 3083.157652] ? drm_lease_owner+0x1a/0x30 [drm] [ 3083.157668] ? drm_mode_cursor2_ioctl+0x10/0x10 [drm] [ 3083.157681] drm_ioctl_kernel+0xa7/0xf0 [drm] [ 3083.157696] drm_ioctl+0x45b/0x560 [drm] [ 3083.157711] ? drm_mode_cursor2_ioctl+0x10/0x10 [drm] [ 3083.157725] ? drm_getstats+0x20/0x20 [drm] [ 3083.157729] ? timerqueue_del+0x49/0x80 [ 3083.157732] ? __remove_hrtimer+0x62/0xb0 [ 3083.157735] ? hrtimer_try_to_cancel+0x173/0x210 [ 3083.157738] do_vfs_ioctl+0x13b/0x880 [ 3083.157741] ? ioctl_preallocate+0x140/0x140 [ 3083.157744] ? _raw_spin_unlock_irq+0xe/0x30 [ 3083.157746] ? do_setitimer+0x234/0x370 [ 3083.157750] ? SyS_setitimer+0x19e/0x1b0 [ 3083.157752] ? SyS_alarm+0x140/0x140 [ 3083.157755] ? __rcu_read_unlock+0x66/0x80 [ 3083.157757] ? __fget+0xc4/0x100 [ 3083.157760] SyS_ioctl+0x74/0x80 [ 3083.157763] entry_SYSCALL_64_fastpath+0x1a/0x7d [ 3083.157765] RIP: 0033:0x7f6135d0c6a7 [ 3083.157767] RSP: 002b:00007fff01451888 EFLAGS: 00003246 ORIG_RAX: 0000000000000010 [ 3083.157769] RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007f6135d0c6a7 [ 3083.157771] RDX: 00007fff01451950 RSI: 00000000c01864b0 RDI: 000000000000000c [ 3083.157772] RBP: 00007f613076f600 R08: 0000000000000001 R09: 0000000000000000 [ 3083.157773] R10: 0000000000000060 R11: 0000000000003246 R12: 0000000000000000 [ 3083.157774] R13: 0000000000000060 R14: 000000000000001b R15: 0000000000000060 [ 3083.157779] Allocated by task 831: [ 3083.157783] kmem_cache_alloc+0xc0/0x200 [ 3083.157822] i915_gem_request_await_dma_fence+0x2c4/0x5d0 [i915] [ 3083.157861] i915_gem_request_await_object+0x321/0x370 [i915] [ 3083.157900] i915_gem_do_execbuffer+0x1165/0x19c0 [i915] [ 3083.157937] i915_gem_execbuffer2+0x1ad/0x550 [i915] [ 3083.157950] drm_ioctl_kernel+0xa7/0xf0 [drm] [ 3083.157962] drm_ioctl+0x45b/0x560 [drm] [ 3083.157964] do_vfs_ioctl+0x13b/0x880 [ 3083.157966] SyS_ioctl+0x74/0x80 [ 3083.157968] entry_SYSCALL_64_fastpath+0x1a/0x7d [ 3083.157971] Freed by task 831: [ 3083.157973] kmem_cache_free+0x77/0x220 [ 3083.158012] i915_gem_request_retire+0x72c/0xa70 [i915] [ 3083.158051] i915_gem_request_alloc+0x1e9/0x8b0 [i915] [ 3083.158089] i915_gem_do_execbuffer+0xa96/0x19c0 [i915] [ 3083.158127] i915_gem_execbuffer2+0x1ad/0x550 [i915] [ 3083.158140] drm_ioctl_kernel+0xa7/0xf0 [drm] [ 3083.158153] drm_ioctl+0x45b/0x560 [drm] [ 3083.158155] do_vfs_ioctl+0x13b/0x880 [ 3083.158156] SyS_ioctl+0x74/0x80 [ 3083.158158] entry_SYSCALL_64_fastpath+0x1a/0x7d [ 3083.158162] The buggy address belongs to the object at ffff8806bf20f400 which belongs to the cache i915_dependency of size 64 [ 3083.158166] The buggy address is located 0 bytes inside of 64-byte region [ffff8806bf20f400, ffff8806bf20f440) [ 3083.158168] The buggy address belongs to the page: [ 3083.158171] page:00000000d43decc4 count:1 mapcount:0 mapping: (null) index:0x0 [ 3083.158174] flags: 0x17ffe0000000100(slab) [ 3083.158179] raw: 017ffe0000000100 0000000000000000 0000000000000000 0000000180200020 [ 3083.158182] raw: ffffea001afc16c0 0000000500000005 ffff880731b881c0 0000000000000000 [ 3083.158184] page dumped because: kasan: bad access detected [ 3083.158187] Memory state around the buggy address: [ 3083.158190] ffff8806bf20f300: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc [ 3083.158192] ffff8806bf20f380: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc [ 3083.158195] >ffff8806bf20f400: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc [ 3083.158196] ^ [ 3083.158199] ffff8806bf20f480: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc [ 3083.158201] ffff8806bf20f500: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc [ 3083.158203] ================================================================== Reported-by:Alexandru Chirvasitu <achirvasub@gmail.com> Reported-by:
Mike Keehan <mike@keehan.net> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104436 Fixes: 1f181225 ("drm/i915/execlists: Keep request->priority for its lifetime") Signed-off-by:
-
- 05 Jan, 2018 2 commits
-
-
Kenneth Graunke authored
Geminilake requires the 3D driver to select whether barriers are intended for compute shaders, or tessellation control shaders, by whacking a "Barrier Mode" bit in SLICE_COMMON_ECO_CHICKEN1 when switching pipelines. Failure to do this properly can result in GPU hangs. Unfortunately, this means it needs to switch mid-batch, so only userspace can properly set it. To facilitate this, the kernel needs to whitelist the register. The workarounds page currently tags this as applying to Broxton only, but that doesn't make sense. The documentation for the register it references says the bit userspace is supposed to toggle only exists on Geminilake. Empirically, the Mesa patch to toggle this bit appears to fix intermittent GPU hangs in tessellation control shader barrier tests on Geminilake; we haven't seen those hangs on Broxton. v2: Mention WA #0862 in the comment (it doesn't have a name). Signed-off-by:
Kenneth Graunke <kenneth@whitecape.org> Acked-by:
-
Anusha Srivatsa authored
There is a new version of DMC available for CNL. The release notes mentions: 1. Fix for the issue where DC_STATE was getting enabled even when disabled by driver causing data corruption v2: Since the firmware is merged to linux-firmware.git, add MODULE_FIRMWARE. v3: rebased. Correct commit message(Jani) Cc: Jani Saarinen <jani.saarinen@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
Anusha Srivatsa <anusha.srivatsa@intel.com> Reviewed-by:
-
