- 03 4月, 2019 1 次提交
-
-
由 Peter Zijlstra 提交于
New tooling noticed this: drivers/gpu/drm/i915/i915_gem_execbuffer.o: warning: objtool: .altinstr_replacement+0x3c: redundant UACCESS disable drivers/gpu/drm/i915/i915_gem_execbuffer.o: warning: objtool: .altinstr_replacement+0x66: redundant UACCESS disable You don't need user_access_end() if user_access_begin() fails. Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: NIngo Molnar <mingo@kernel.org>
-
- 28 3月, 2019 1 次提交
-
-
由 José Roberto de Souza 提交于
GT VEBOX DISABLE is only 4 bits wide but it was using a 8 bits wide mask, the remaning reserved bits is set to 0 causing 4 more nonexistent VEBOX engines being detected as enabled, triggering the BUG_ON() because of mismatch between vebox_mask and newly added VEBOX_MASK(). [ 64.081621] [drm:intel_device_info_init_mmio [i915]] vdbox enable: 0005, instances: 0005 [ 64.081763] [drm:intel_device_info_init_mmio [i915]] vebox enable: 00f1, instances: 0001 [ 64.081825] intel_device_info_init_mmio:925 GEM_BUG_ON(vebox_mask != ({ unsigned int first__ = (VECS0); unsigned int count__ = (2); ((&(dev_priv)->__info)->engine_mask & (((~0UL) - (1UL << (first__)) + 1) & (~0UL >> (64 - 1 - (first__ + count__ - 1))))) >> first__; })) [ 64.082047] ------------[ cut here ]------------ [ 64.082054] kernel BUG at drivers/gpu/drm/i915/intel_device_info.c:925! BSpec: 20680 Fixes: 26376a7e ("drm/i915/icl: Check for fused-off VDBOX and VEBOX instances") Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Oscar Mateo <oscar.mateo@intel.com> Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com> Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190326230223.26336-1-jose.souza@intel.com (cherry picked from commit 547fcf9b) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
- 27 3月, 2019 1 次提交
-
-
由 Dan Carpenter 提交于
The live_context() function returns error pointers. It never returns NULL. Fixes: 9c1477e8 ("drm/i915/selftests: Exercise adding requests to a full GGTT") Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com> Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com> Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190326050843.GA20038@kadam (cherry picked from commit 602cbe8e) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
- 26 3月, 2019 1 次提交
-
-
由 Ville Syrjälä 提交于
If I'm reading the spec right AML 0x87CA is a Y SKU, so it should be marked as ULX in our old style terminology. Cc: stable@vger.kernel.org Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Fixes: c0c46ca4 ("drm/i915/aml: Add new Amber Lake PCI ID") Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190322204944.23613-1-ville.syrjala@linux.intel.comReviewed-by: NJosé Roberto de Souza <jose.souza@intel.com> (cherry picked from commit 57b1c446) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
- 25 3月, 2019 6 次提交
-
-
由 Neil Armstrong 提交于
DMT monitors does not necessarely report a maximum TMDS clock in a VSDB EDID extension. In this case, all modes are wrongly rejected, including the DRM fallback EDID. This patch only rejects modes whith clock > max_tmds_clock if the max_tmds_clock is specified. This will only reject 4:2:0 HDMI2.0 modes, who reports a clock > max_tmds_clock. Reported-by: NMaxime Jourdan <mjourdan@baylibre.com> Fixes: d7d8fb70 ("drm/meson: add HDMI div40 TMDS mode") Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com> Tested-by: NMaxime Jourdan <mjourdan@baylibre.com> Reviewed-by: NMaxime Jourdan <mjourdan@baylibre.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190320081110.1718-1-narmstrong@baylibre.com
-
由 Jean-Philippe Brucker 提交于
meson_drv_unbind() doesn't unregister the IRQ handler, which can lead to use-after-free if the IRQ fires after unbind: [ 64.656876] Unable to handle kernel paging request at virtual address ffff000011706dbc ... [ 64.662001] pc : meson_irq+0x18/0x30 [meson_drm] I'm assuming that a similar problem could happen on the error path of bind(), so uninstall the IRQ handler there as well. Fixes: bbbe775e ("drm: Add support for Amlogic Meson Graphic Controller") Signed-off-by: NJean-Philippe Brucker <jean-philippe.brucker@arm.com> Acked-by: NNeil Armstrong <narmstrong@baylibre.com> Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190322152657.13752-2-jean-philippe.brucker@arm.com
-
由 Jean-Philippe Brucker 提交于
meson_drv_bind() registers a meson_drm struct as the device's privdata, but meson_drv_unbind() tries to retrieve a drm_device. This may cause a segfault on shutdown: [ 5194.593429] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000197 ... [ 5194.788850] Call trace: [ 5194.791349] drm_dev_unregister+0x1c/0x118 [drm] [ 5194.795848] meson_drv_unbind+0x50/0x78 [meson_drm] Retrieve the right pointer in meson_drv_unbind(). Fixes: bbbe775e ("drm: Add support for Amlogic Meson Graphic Controller") Signed-off-by: NJean-Philippe Brucker <jean-philippe.brucker@arm.com> Acked-by: NNeil Armstrong <narmstrong@baylibre.com> Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190322152657.13752-1-jean-philippe.brucker@arm.com
-
由 Robert Tarasov 提交于
Now drm/udl driver uses drm_do_get_edid() function to retrieve and validate all blocks of EDID data. Old approach had insufficient validation routine and had problems with retrieving of extra blocks Signed-off-by: NRobert Tarasov <tutankhamen@chromium.org> Reviewed-by: NJani Nikula <jani.nikula@intel.com> Signed-off-by: NDave Airlie <airlied@redhat.com> [airlied: Fix spelling mistakes] Link: https://patchwork.freedesktop.org/patch/msgid/20190314225339.162386-1-tutankhamen@chromium.org
-
由 Noralf Trønnes 提交于
If userspace has open fd(s) when drm_dev_unplug() is run, it will result in drm_dev_unregister() being called twice. First in drm_dev_unplug() and then later in drm_release() through the call to drm_put_dev(). Since userspace already holds a ref on drm_device through the drm_minor, it's not necessary to add extra ref counting based on no open file handles. Instead just drm_dev_put() unconditionally in drm_dev_unplug(). We now have this: - Userpace holds a ref on drm_device as long as there's open fd(s) - The driver holds a ref on drm_device as long as it's bound to the struct device When both sides are done with drm_device, it is released. Signed-off-by: NNoralf Trønnes <noralf@tronnes.org> Reviewed-by: NOleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: NSean Paul <sean@poorly.run> Signed-off-by: NDave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190208140103.28919-2-noralf@tronnes.org
-
由 Dave Airlie 提交于
If the downscaling fails and we end up with a best_depth of 0, then ignore it. This actually works around a cascade of failure, but it the simplest fix for now. The scaling patch broke the udl driver, as the udl driver doesn't expose planes at all, so gets the two default 32-bit formats, but the udl driver then ask for 16bpp fbdev, and the scaling code falls over. This fixes the udl driver since the scaled depth support was added. Fixes: f4bd542b ("drm/fb-helper: Scale back depth to supported maximum") Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: NLinus Walleij <linus.walleij@linaro.org> Signed-off-by: NDave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190315014621.21816-2-airlied@gmail.com
-
- 22 3月, 2019 8 次提交
-
-
由 Anders Roxell 提交于
When CONFIG_IOMMU_API isn't set the following warnings pops up: drivers/gpu/drm/tegra/vic.c: In function ‘vic_boot’: drivers/gpu/drm/tegra/vic.c:110:31: error: implicit declaration of function ‘dev_iommu_fwspec_get’; did you mean ‘iommu_fwspec_free’? [-Werror=implicit-function-declaration] struct iommu_fwspec *spec = dev_iommu_fwspec_get(vic->dev); ^~~~~~~~~~~~~~~~~~~~ iommu_fwspec_free drivers/gpu/drm/tegra/vic.c:110:31: warning: initialization of ‘struct iommu_fwspec *’ from ‘int’ makes pointer from integer without a cast [-Wint-conversion] drivers/gpu/drm/tegra/vic.c:117:19: error: ‘struct iommu_fwspec’ has no member named ‘num_ids’ if (spec && spec->num_ids > 0) { ^~ drivers/gpu/drm/tegra/vic.c:118:16: error: ‘struct iommu_fwspec’ has no member named ‘ids’ value = spec->ids[0] & 0xffff; ^~ Rework so that its inside a '#ifdef CONFIG_IOMMU_API' block. Fixes: f3779cb1 ("drm/tegra: vic: Support stream ID register programming") Signed-off-by: NAnders Roxell <anders.roxell@linaro.org> Signed-off-by: NThierry Reding <treding@nvidia.com>
-
由 Thierry Reding 提交于
Reported-by: NDan Carpenter <dan.carpenter@oracle.com> Signed-off-by: NThierry Reding <treding@nvidia.com>
-
由 Jérôme Glisse 提交于
Empty chunk do not have a bo associated with them so no need to pin/unpin on suspend/resume. This fix suspend/resume on 5.1rc1 when NOUVEAU_SVM is enabled. Signed-off-by: NJérôme Glisse <jglisse@redhat.com> Reviewed-by: NTobias Klausmann <tobias.johannes.klausmann@mni.thm.de> Tested-by: NTobias Klausmann <tobias.johannes.klausmann@mni.thm.de> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: dri-devel@lists.freedesktop.org Cc: nouveau@lists.freedesktop.org Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 YueHaibing 提交于
pm_runtime_get_sync returns negative on failure. Fixes: eaeb9010 ("drm/nouveau/debugfs: Wake up GPU before doing any reclocking") Signed-off-by: NYueHaibing <yuehaibing@huawei.com> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Dan Carpenter 提交于
The hmm_devmem_add() function doesn't return NULL, it returns error pointers. Fixes: 5be73b69 ("drm/nouveau/dmem: device memory helpers for SVM") Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 YueHaibing 提交于
Fixes gcc '-Wunused-but-set-variable' warning: drivers/gpu/drm/nouveau/nouveau_dmem.c: In function 'nouveau_dmem_free': drivers/gpu/drm/nouveau/nouveau_dmem.c:103:22: warning: variable 'drm' set but not used [-Wunused-but-set-variable] struct nouveau_drm *drm; ^ Signed-off-by: NYueHaibing <yuehaibing@huawei.com> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Manasi Navare 提交于
This patch fixes the PORT_SYNC_MODE_MASTER_SELECT macro to correctly do the left shifting to set the port sync master select correctly. I have tested this fix on ICL. Fixes: 49edbd49 ("drm/i915/icl: Define TRANS_DDI_FUNC_CTL DSI registers") Cc: Madhav Chauhan <madhav.chauhan@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: <stable@vger.kernel.org> # v5.0+ Signed-off-by: NManasi Navare <manasi.d.navare@intel.com> Reviewed-by: NJani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190319221847.21311-1-manasi.d.navare@intel.com (cherry picked from commit 7264aebb) Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
-
由 Nicholas Kazlauskas 提交于
[Why] Black screens or artifacting can occur when enabling FreeSync outside of the supported range of the monitor. This can happen since the supported range isn't always the min/max vrefresh range available for the monitor. [How] There was previously a fix that prevented this from happening in the low range but it didn't cover the upper range. Expand the condition to include both. Cc: Sun peng Li <Sunpeng.Li@amd.com> Cc: Harry Wentland <Harry.Wentland@amd.com> Signed-off-by: NNicholas Kazlauskas <nicholas.kazlauskas@amd.com> Acked-by: NAlex Deucher <alexander.deucher@amd.com> Reviewed-by: NHarry Wentland <harry.wentland@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
- 21 3月, 2019 1 次提交
-
-
由 Andrzej Hajda 提交于
MIXER on Exynos5 SoCs uses different synchronisation method than Exynos4 to update internal state (shadow registers). Apparently the driver implements it incorrectly. The rule should be as follows: - do not request updating registers until previous request was finished, ie. MXR_CFG_LAYER_UPDATE_COUNT must be 0. - before setting registers synchronisation on VSYNC should be turned off, ie. MXR_STATUS_SYNC_ENABLE should be reset, - after finishing MXR_STATUS_SYNC_ENABLE should be set again. The patch hopefully implements it correctly. Below sample kernel log from page fault caused by the bug: [ 25.670038] exynos-sysmmu 14650000.sysmmu: 14450000.mixer: PAGE FAULT occurred at 0x2247b800 [ 25.677888] ------------[ cut here ]------------ [ 25.682164] kernel BUG at ../drivers/iommu/exynos-iommu.c:450! [ 25.687971] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM [ 25.693778] Modules linked in: [ 25.696816] CPU: 5 PID: 1553 Comm: fb-release_test Not tainted 5.0.0-rc7-01157-g5f86b1566bdd #136 [ 25.705646] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) [ 25.711710] PC is at exynos_sysmmu_irq+0x1c0/0x264 [ 25.716470] LR is at lock_is_held_type+0x44/0x64 v2: added missing MXR_CFG_LAYER_UPDATE bit setting in mixer_enable_sync Reported-by: NMarian Mihailescu <mihailescu2m@gmail.com> Signed-off-by: NAndrzej Hajda <a.hajda@samsung.com> Signed-off-by: NInki Dae <inki.dae@samsung.com>
-
- 20 3月, 2019 4 次提交
-
-
由 Thomas Zimmermann 提交于
When calling vmw_fb_set_par(), the mode stored in par->set_mode gets free'd twice. The first free is in vmw_fb_kms_detach(), the second is near the end of vmw_fb_set_par() under the name of 'old_mode'. The mode-setting code only works correctly if the mode doesn't actually change. Removing 'old_mode' in favor of using par->set_mode directly fixes the problem. Cc: <stable@vger.kernel.org> Fixes: a278724a ("drm/vmwgfx: Implement fbdev on kms v2") Signed-off-by: NThomas Zimmermann <tzimmermann@suse.de> Reviewed-by: NDeepak Rawat <drawat@vmware.com> Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
-
由 Deepak Rawat 提交于
If it's not a system error and get_node implementation accommodate the buffer object then it should return 0 with memm::mm_node set to NULL. v2: Test for id != -ENOMEM instead of id == -ENOSPC. Cc: <stable@vger.kernel.org> Fixes: 4eb085e4 ("drm/vmwgfx: Convert to new IDA API") Signed-off-by: NDeepak Rawat <drawat@vmware.com> Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com> Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
-
由 Christian König 提交于
We only need to clear the bit in a 32bit integer. This fixes a crah on ARM64 and PPC64LE caused by "drm/amdgpu: update the vm invalidation engine layout V2" Signed-off-by: NChristian König <christian.koenig@amd.com> Acked-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Christian König 提交于
This reverts commit 8466cc61. It can trigger a reference counter bug in TTM. Need to investigate further, but for now revert the offending change. Signed-off-by: NChristian König <christian.koenig@amd.com> Reviewed-by: NMichel Dänzer <michel.daenzer@amd.com> Tested-by: NMichel Dänzer <michel.daenzer@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
- 19 3月, 2019 4 次提交
-
-
由 Chris Wilson 提交于
We assumed that vm_mmap() would reject an attempt to mmap past the end of the filp (our object), but we were wrong. Applications that tried to use the mmap beyond the end of the object would be greeted by a SIGBUS. After this patch, those applications will be told about the error on creating the mmap, rather than at a random moment on later access. Reported-by: NAntonio Argenziano <antonio.argenziano@intel.com> Testcase: igt/gem_mmap/bad-size Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Antonio Argenziano <antonio.argenziano@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: stable@vger.kernel.org Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190314075829.16838-1-chris@chris-wilson.co.uk (cherry picked from commit 794a11cb) Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
-
由 Chris Wilson 提交于
ffs() is 1-indexed, but we want to use it as an index into an array, so use __ffs() instead. Fixes: eb8d0f5a ("drm/i915: Remove GPU reset dependence on struct_mutex") Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190315163933.19352-1-chris@chris-wilson.co.uk (cherry picked from commit 9073e5b2) Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
-
由 Thomas Preston 提交于
We rely on VBT DDI port info for eDP detection on GEN9 platforms and above. This breaks GEN9 platforms which don't have VBT because port A eDP now defaults to false. Fix this by defaulting to true when VBT is missing. Fixes: a98d9c1d ("drm/i915/ddi: Rely on VBT DDI port info for eDP detection") Signed-off-by: NThomas Preston <thomas.preston@codethink.co.uk> Signed-off-by: NJani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190306200618.17405-1-thomas.preston@codethink.co.uk (cherry picked from commit 2131bc0c) Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
-
由 Jonas Karlman 提交于
NV12 framebuffers produced by the VPU shows distorted on RK3288 after win has been disabled when scaling is active. This issue can be reproduced using a 1080p modeset by: - Scale a 1280x720 NV12 framebuffer to 1920x1080 on win0 - Disable win0 - Display a 1920x1080 NV12 framebuffer without scaling on win0 - Output will now show the framebuffer distorted And by: - Scale a 1280x720 NV12 framebuffer to 1920x1080 - Change to a 720p modeset (win gets disabled and scaling reset to none) - Output will now show the framebuffer distorted Fix this by setting scale mode to none when win is disabled. Fixes: 4c156c21 ("drm/rockchip: vop: support plane scale") Cc: stable@vger.kernel.org Signed-off-by: NJonas Karlman <jonas@kwiboo.se> Signed-off-by: NHeiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/AM3PR03MB0966DE3E19BACE07328CD637AC7D0@AM3PR03MB0966.eurprd03.prod.outlook.com
-
- 18 3月, 2019 3 次提交
-
-
由 Eric Biggers 提交于
If drm_gem_handle_create() fails in vkms_gem_create(), then the vkms_gem_object is freed twice: once when the reference is dropped by drm_gem_object_put_unlocked(), and again by the extra calls to drm_gem_object_release() and kfree(). Fix it by skipping the second release and free. This bug was originally found in the vgem driver by syzkaller using fault injection, but I noticed it's also present in the vkms driver. Fixes: 559e50fd ("drm/vkms: Add dumb operations") Cc: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com> Cc: Haneen Mohammed <hamohammed.sa@gmail.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: stable@vger.kernel.org Signed-off-by: NEric Biggers <ebiggers@google.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NRodrigo Siqueira <rodrigosiqueiramelo@gmail.com> Signed-off-by: NRodrigo Siqueira <rodrigosiqueiramelo@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190226220858.214438-1-ebiggers@kernel.orgSigned-off-by: NMaxime Ripard <maxime.ripard@bootlin.com>
-
由 Eric Biggers 提交于
If drm_gem_handle_create() fails in vgem_gem_create(), then the drm_vgem_gem_object is freed twice: once when the reference is dropped by drm_gem_object_put_unlocked(), and again by __vgem_gem_destroy(). This was hit by syzkaller using fault injection. Fix it by skipping the second free. Reported-by: syzbot+e73f2fb5ed5a5df36d33@syzkaller.appspotmail.com Fixes: af33a919 ("drm/vgem: Enable dmabuf import interfaces") Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Laura Abbott <labbott@redhat.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: stable@vger.kernel.org Signed-off-by: NEric Biggers <ebiggers@google.com> Acked-by: NLaura Abbott <labbott@redhat.com> Signed-off-by: NRodrigo Siqueira <rodrigosiqueiramelo@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190226214451.195123-1-ebiggers@kernel.orgSigned-off-by: NMaxime Ripard <maxime.ripard@bootlin.com>
-
由 Dave Airlie 提交于
When Daniel removed struct_mutex he didn't fix this call to the unlocked variant which is required since we no longer use struct mutex. This fixes a bunch of: WARNING: CPU: 4 PID: 1370 at drivers/gpu/drm/drm_gem.c:931 drm_gem_object_put+0x2b/0x30 [drm] Modules linked in: udl xt_CHECKSUM ipt_MASQUERADE tun bridge stp llc nf_conntrack_netbios_ns nf_conntrack_broadcast xt_CT ip6t> CPU: 4 PID: 1370 Comm: Xorg Not tainted 5.0.0+ #2 backtraces when you plug in a udl device. Fixes: ae358dac (drm/udl: Get rid of dev->struct_mutex usage) Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Cc: Sean Paul <seanpaul@chromium.org> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 13 3月, 2019 1 次提交
-
-
由 Souptick Joarder 提交于
Convert to use vm_fault_t type as return type for fault handler. kbuild reported warning during testing of *mm-create-the-new-vm_fault_t-type.patch* available in below link - https://patchwork.kernel.org/patch/10752741/ kernel/memremap.c:46:34: warning: incorrect type in return expression (different base types) kernel/memremap.c:46:34: expected restricted vm_fault_t kernel/memremap.c:46:34: got int This patch has fixed the warnings and also hmm_devmem_fault() is converted to return vm_fault_t to avoid further warnings. [sfr@canb.auug.org.au: drm/nouveau/dmem: update for struct hmm_devmem_ops member change] Link: http://lkml.kernel.org/r/20190220174407.753d94e5@canb.auug.org.au Link: http://lkml.kernel.org/r/20190110145900.GA1317@jordon-HP-15-Notebook-PCSigned-off-by: NSouptick Joarder <jrdr.linux@gmail.com> Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au> Reviewed-by: NJérôme Glisse <jglisse@redhat.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 12 3月, 2019 3 次提交
-
-
由 shaoyunl 提交于
GC owner suggested the setting should be applied which is missed by HW default Signed-off-by: Nshaoyunl <shaoyun.liu@amd.com> Acked-by: NAlex Deucher <alexander.deucher@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Evan Quan 提交于
Set sampling period as 500ms to provide a smooth power reading output. Also, correct the register for power reading. Signed-off-by: NEvan Quan <evan.quan@amd.com> Reviewed-by: NFeifei Xu <Feifei.Xu@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
由 Evan Quan 提交于
A workaround to override the fan target temperature in SMC table. Signed-off-by: NEvan Quan <evan.quan@amd.com> Reviewed-by: Kenneth Feng <kenneth.feng@amd.com Acked-by: NAlex Deucher <alexander.deucher@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
- 09 3月, 2019 6 次提交
-
-
由 Tvrtko Ursulin 提交于
Legacy behaviour was to allow non-page-aligned mmap requests, as does the linux mmap(2) implementation by virtue of automatically rounding up for the caller. To avoid breaking legacy userspace relax the newly introduced fix. Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Fixes: 5c4604e7 ("drm/i915: Prevent a race during I915_GEM_MMAP ioctl with WC set") Reported-by: NGuenter Roeck <linux@roeck-us.net> Cc: Adam Zabrocki <adamza@microsoft.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: <stable@vger.kernel.org> # v4.0+ Cc: Akash Goel <akash.goel@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: intel-gfx@lists.freedesktop.org Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190305110409.28633-1-tvrtko.ursulin@linux.intel.com (cherry picked from commit a90e1948) Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
-
由 José Roberto de Souza 提交于
Atomic state needs to be put even if the commit was successful. Fixes: dba14b27 ("drm/i915: Reinitialize sink scrambling/TMDS clock ratio on HPD") Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Lyude Paul <lyude@redhat.com> Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190302003349.19189-1-jose.souza@intel.com (cherry picked from commit a551cd66) Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
-
由 Chris Wilson 提交于
We may race the interrupt signaling with retirement, in which case the order in which we acquire the reference inside the interrupt is vital to provide the correct barrier against the request being freed in retirement, i.e. we need to acquire our reference before marking the breadcrumb as cancelled (as soon as the breadcrumb is cancelled retirement may drop its reference to the request without serialisation with the interrupt handler). <3>[ 683.372226] BUG i915_request (Tainted: G U ): Object already free <3>[ 683.372269] ----------------------------------------------------------------------------- <4>[ 683.372323] Disabling lock debugging due to kernel taint <3>[ 683.372393] INFO: Allocated in i915_request_alloc+0x169/0x810 [i915] age=0 cpu=2 pid=1420 <3>[ 683.372412] kmem_cache_alloc+0x21c/0x280 <3>[ 683.372478] i915_request_alloc+0x169/0x810 [i915] <3>[ 683.372540] i915_gem_do_execbuffer+0x84e/0x1ae0 [i915] <3>[ 683.372603] i915_gem_execbuffer2_ioctl+0x11b/0x420 [i915] <3>[ 683.372617] drm_ioctl_kernel+0x83/0xf0 <3>[ 683.372626] drm_ioctl+0x2f3/0x3b0 <3>[ 683.372636] do_vfs_ioctl+0xa0/0x6e0 <3>[ 683.372645] ksys_ioctl+0x35/0x60 <3>[ 683.372654] __x64_sys_ioctl+0x11/0x20 <3>[ 683.372664] do_syscall_64+0x55/0x190 <3>[ 683.372675] entry_SYSCALL_64_after_hwframe+0x49/0xbe <3>[ 683.372740] INFO: Freed in i915_request_retire_upto+0xfb/0x2e0 [i915] age=0 cpu=0 pid=1419 <3>[ 683.372807] i915_request_retire_upto+0xfb/0x2e0 [i915] <3>[ 683.372870] i915_request_add+0x3bd/0x9d0 [i915] <3>[ 683.372931] i915_gem_do_execbuffer+0x141c/0x1ae0 [i915] <3>[ 683.372991] i915_gem_execbuffer2_ioctl+0x11b/0x420 [i915] <3>[ 683.373001] drm_ioctl_kernel+0x83/0xf0 <3>[ 683.373008] drm_ioctl+0x2f3/0x3b0 <3>[ 683.373015] do_vfs_ioctl+0xa0/0x6e0 <3>[ 683.373023] ksys_ioctl+0x35/0x60 <3>[ 683.373030] __x64_sys_ioctl+0x11/0x20 <3>[ 683.373037] do_syscall_64+0x55/0x190 <3>[ 683.373045] entry_SYSCALL_64_after_hwframe+0x49/0xbe <3>[ 683.373054] INFO: Slab 0x0000000079bcdd71 objects=30 used=2 fp=0x000000006d77b8af flags=0x8000000000010201 <3>[ 683.373069] INFO: Object 0x000000006d77b8af @offset=24000 fp=0x000000007b061eab <3>[ 683.373083] Redzone 00000000ee47ef28: bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................ <3>[ 683.373097] Redzone 000000000cb91471: bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................ <3>[ 683.373111] Redzone 00000000cf2b86ee: bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................ <3>[ 683.373125] Redzone 00000000f1f5a2cd: bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................ <3>[ 683.373139] Object 000000006d77b8af: 00 00 00 00 5a 5a 5a 5a 00 3c 49 c0 ff ff ff ff ....ZZZZ.<I..... <3>[ 683.373153] Object 000000006f9b6204: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZZZZZ <3>[ 683.373167] Object 0000000091410ffb: e0 dd 6b fa 87 9f ff ff e0 dd 6b fa 87 9f ff ff ..k.......k..... <3>[ 683.373181] Object 000000004cdf799d: 20 de 6b fa 87 9f ff ff 3d 00 00 00 00 00 00 00 .k.....=....... <3>[ 683.373195] Object 00000000545afebc: aa b3 00 00 00 00 00 00 0f 00 00 00 00 00 00 00 ................ <3>[ 683.373209] Object 00000000e4a394a8: 25 bd bd 1b 9f 00 00 00 00 00 00 00 5a 5a 5a 5a %...........ZZZZ <3>[ 683.373223] Object 0000000029a7878a: 00 00 00 00 ad 4e ad de ff ff ff ff 5a 5a 5a 5a .....N......ZZZZ <3>[ 683.373237] Object 00000000d37797b3: ff ff ff ff ff ff ff ff e8 6e 57 c0 ff ff ff ff .........nW..... <3>[ 683.373251] Object 00000000d50414f6: 00 b3 c8 8e ff ff ff ff 80 b0 c8 8e ff ff ff ff ................ <3>[ 683.373265] Object 00000000c28e8847: 41 01 4b c0 ff ff ff ff 00 00 88 8e 88 9f ff ff A.K............. <3>[ 683.373279] Object 00000000c74212ab: 38 c1 6d 8a 88 9f ff ff 58 21 74 8a 88 9f ff ff 8.m.....X!t..... <3>[ 683.373293] Object 000000000d8012cf: c0 c1 6d 8a 88 9f ff ff 58 79 dd d9 87 9f ff ff ..m.....Xy...... <3>[ 683.373306] Object 00000000c9900b91: 98 d0 4e 8a 88 9f ff ff 58 3c e8 9b 88 9f ff ff ..N.....X<...... <3>[ 683.373320] Object 0000000044bb8c3d: 58 3c e8 9b 88 9f ff ff 64 f5 04 00 00 00 00 00 X<......d....... <3>[ 683.373334] Object 00000000180c4cca: 00 00 00 00 ad 4e ad de ff ff ff ff 5a 5a 5a 5a .....N......ZZZZ <3>[ 683.373348] Object 00000000c9044498: ff ff ff ff ff ff ff ff e0 6e 57 c0 ff ff ff ff .........nW..... <3>[ 683.373362] Object 0000000072d0dfb3: 00 00 00 00 00 00 00 00 c0 b1 c8 8e ff ff ff ff ................ <3>[ 683.373376] Object 0000000081f198b9: 55 01 4b c0 ff ff ff ff d8 de 6b fa 87 9f ff ff U.K.......k..... <3>[ 683.373390] Object 000000006a375a13: d8 de 6b fa 87 9f ff ff cc 05 39 c0 ff ff ff ff ..k.......9..... <3>[ 683.373404] Object 00000000b8392dd1: ff ff ff ff 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ....ZZZZZZZZZZZZ <3>[ 683.373418] Object 00000000e5c1bbcb: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZZZZZ <3>[ 683.373432] Object 00000000199feccd: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZZZZZ <3>[ 683.373446] Object 0000000020f5e08b: 20 df 6b fa 87 9f ff ff 20 df 6b fa 87 9f ff ff .k..... .k..... <3>[ 683.373460] Object 0000000090591b0f: 30 df 6b fa 87 9f ff ff 30 df 6b fa 87 9f ff ff 0.k.....0.k..... <3>[ 683.373473] Object 00000000232f7cd0: 40 df 6b fa 87 9f ff ff 40 df 6b fa 87 9f ff ff @.k.....@.k..... <3>[ 683.373487] Object 0000000060458027: 50 df 6b fa 87 9f ff ff 50 df 6b fa 87 9f ff ff P.k.....P.k..... <3>[ 683.373501] Object 00000000e3c82ce2: 06 00 00 00 00 00 00 00 5a 5a 5a 5a 5a 5a 5a 5a ........ZZZZZZZZ <3>[ 683.373515] Object 00000000ec804eb8: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZZZZZ <3>[ 683.373529] Object 00000000ce7ccc08: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZZZZZ <3>[ 683.373543] Object 000000002dbc575c: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZZZZZ <3>[ 683.373557] Object 00000000b86d3417: 5a 5a 5a 5a 5a 5a 5a 5a 00 de 6b fa 87 9f ff ff ZZZZZZZZ..k..... <3>[ 683.373571] Object 00000000d1e82276: b8 61 dd d9 87 9f ff ff a0 06 00 00 d0 06 00 00 .a.............. <3>[ 683.373585] Object 00000000cc53f969: e8 06 00 00 20 07 00 00 28 07 00 00 00 00 00 00 .... ...(....... <3>[ 683.373599] Object 00000000ea2426d2: 40 0c 8c 7b 88 9f ff ff 00 00 00 00 00 00 00 00 @..{............ <3>[ 683.373613] Object 00000000b860c1c3: 68 0d 8c 7b 88 9f ff ff 68 25 8c 7b 88 9f ff ff h..{....h%.{.... <3>[ 683.373627] Object 0000000016455ea0: 96 d5 05 00 01 00 00 00 00 5a 5a 5a 5a 5a 5a 5a .........ZZZZZZZ <3>[ 683.373640] Object 00000000e66ede82: 00 e0 6b fa 87 9f ff ff 00 e0 6b fa 87 9f ff ff ..k.......k..... <3>[ 683.373654] Object 0000000080964939: 10 e0 6b fa 87 9f ff ff 10 e0 6b fa 87 9f ff ff ..k.......k..... <3>[ 683.373668] Object 00000000e7ffc5dd: 00 00 00 00 00 00 00 00 00 01 00 00 00 00 ad de ................ <3>[ 683.373682] Object 000000000ce9d6ca: 00 02 00 00 00 00 ad de 5a 5a 5a 5a 5a 5a 5a 5a ........ZZZZZZZZ <3>[ 683.373696] Object 00000000386659d0: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZZZZZ <3>[ 683.373710] Redzone 0000000075d2069d: bb bb bb bb bb bb bb bb ........ <3>[ 683.373723] Padding 0000000054e14c6b: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZZZZZ <3>[ 683.373737] Padding 00000000425e5b34: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZZZZZ <3>[ 683.373751] Padding 00000000ad3d4db9: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZZZZZ <4>[ 683.373767] CPU: 1 PID: 151 Comm: kworker/1:2 Tainted: G BU 5.0.0-rc8-g39139489403b-drmtip_236+ #1 <4>[ 683.373769] Hardware name: Intel Corporation Ice Lake Client Platform/IceLake Y LPDDR4x T4 RVP TLC, BIOS ICLSFWR1.R00.3087.A00.1902250334 02/25/2019 <4>[ 683.373773] Workqueue: events delayed_fput <4>[ 683.373775] Call Trace: <4>[ 683.373777] <IRQ> <4>[ 683.373781] dump_stack+0x67/0x9b <4>[ 683.373783] free_debug_processing+0x344/0x370 <4>[ 683.373832] ? intel_engine_breadcrumbs_irq+0x2e4/0x380 [i915] <4>[ 683.373836] __slab_free+0x337/0x4f0 <4>[ 683.373840] ? _raw_spin_unlock_irqrestore+0x39/0x60 <4>[ 683.373844] ? debug_check_no_obj_freed+0x132/0x210 <4>[ 683.373889] ? intel_engine_breadcrumbs_irq+0x2e4/0x380 [i915] <4>[ 683.373892] ? kmem_cache_free+0x275/0x2e0 <4>[ 683.373894] kmem_cache_free+0x275/0x2e0 <4>[ 683.373939] intel_engine_breadcrumbs_irq+0x2e4/0x380 [i915] <4>[ 683.373984] gen8_cs_irq_handler+0x4e/0xa0 [i915] <4>[ 683.374026] gen11_irq_handler+0x24b/0x330 [i915] <4>[ 683.374032] __handle_irq_event_percpu+0x41/0x2d0 <4>[ 683.374034] ? handle_irq_event+0x27/0x50 <4>[ 683.374038] handle_irq_event_percpu+0x2b/0x70 <4>[ 683.374040] handle_irq_event+0x2f/0x50 <4>[ 683.374044] handle_edge_irq+0xe7/0x190 <4>[ 683.374048] handle_irq+0x67/0x160 <4>[ 683.374051] do_IRQ+0x5e/0x130 <4>[ 683.374054] common_interrupt+0xf/0xf Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109827 Fixes: 52c0fdb2 ("drm/i915: Replace global breadcrumbs with per-context interrupt tracking") Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190304114113.371-1-chris@chris-wilson.co.uk (cherry picked from commit e781a7a3) Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
-
由 Chris Wilson 提交于
Prepare a nice little onion unwind to ensure that we always free the spinner if we __sseu_prepare fails. Fixes: c06ee6ff ("drm/i915/selftests: Context SSEU reconfiguration tests") Reported-by: NRadhakrishna Sripada <radhakrishna.sripada@intel.com> Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190215195010.16637-1-chris@chris-wilson.co.ukReviewed-by: NRadhakrishna Sripada <radhakrishna.sripada@intel.com> (cherry picked from commit 2a4a2754) Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
-
由 Chris Wilson 提交于
If we drop the engine lock, we may run execlists_dequeue which may free the priolist. Therefore if we ever drop the execution lock on the engine, we have to discard our cache and refetch the priolist to ensure we do not use a stale pointer. [ 506.418935] [IGT] gem_exec_whisper: starting subtest contexts-priority [ 593.240825] general protection fault: 0000 [#1] SMP [ 593.240863] CPU: 1 PID: 494 Comm: gem_exec_whispe Tainted: G U 5.0.0-rc6+ #100 [ 593.240879] Hardware name: /NUC6CAYB, BIOS AYAPLCEL.86A.0029.2016.1124.1625 11/24/2016 [ 593.240965] RIP: 0010:__i915_schedule+0x1fe/0x320 [i915] [ 593.240981] Code: 48 8b 0c 24 48 89 c3 49 8b 45 28 49 8b 75 20 4c 89 3c 24 48 89 46 08 48 89 30 48 8b 43 08 48 89 4b 08 49 89 5d 20 49 89 45 28 <48> 89 08 45 39 a7 b8 03 00 00 7d 44 45 89 a7 b8 03 00 00 49 8b 85 [ 593.240999] RSP: 0018:ffffc90000057a60 EFLAGS: 00010046 [ 593.241013] RAX: 6b6b6b6b6b6b6b6b RBX: ffff8882582d7870 RCX: ffff88826baba6f0 [ 593.241026] RDX: 0000000000000000 RSI: ffff8882582d6e70 RDI: ffff888273482194 [ 593.241049] RBP: ffffc90000057a68 R08: ffff8882582d7680 R09: ffff8882582d7840 [ 593.241068] R10: 0000000000000000 R11: ffffea00095ebe08 R12: 0000000000000728 [ 593.241105] R13: ffff88826baba6d0 R14: ffffc90000057a40 R15: ffff888273482158 [ 593.241120] FS: 00007f4613fb3900(0000) GS:ffff888277a80000(0000) knlGS:0000000000000000 [ 593.241133] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 593.241146] CR2: 00007f57d3c66a84 CR3: 000000026e2b6000 CR4: 00000000001406e0 [ 593.241158] Call Trace: [ 593.241233] i915_schedule+0x1f/0x30 [i915] [ 593.241326] i915_request_add+0x1a9/0x290 [i915] [ 593.241393] i915_gem_do_execbuffer+0x45f/0x1150 [i915] [ 593.241411] ? init_object+0x49/0x80 [ 593.241425] ? ___slab_alloc.constprop.91+0x4b8/0x4e0 [ 593.241491] ? i915_gem_execbuffer2_ioctl+0x99/0x380 [i915] [ 593.241563] ? i915_gem_execbuffer_ioctl+0x270/0x270 [i915] [ 593.241629] i915_gem_execbuffer2_ioctl+0x1bb/0x380 [i915] [ 593.241705] ? i915_gem_execbuffer_ioctl+0x270/0x270 [i915] [ 593.241724] drm_ioctl_kernel+0x81/0xd0 [ 593.241738] drm_ioctl+0x1a7/0x310 [ 593.241803] ? i915_gem_execbuffer_ioctl+0x270/0x270 [i915] [ 593.241819] ? __update_load_avg_se+0x1c9/0x240 [ 593.241834] ? pick_next_entity+0x7e/0x120 [ 593.241851] do_vfs_ioctl+0x88/0x5d0 [ 593.241880] ksys_ioctl+0x35/0x70 [ 593.241894] __x64_sys_ioctl+0x11/0x20 [ 593.241907] do_syscall_64+0x44/0xf0 [ 593.241924] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 593.241940] RIP: 0033:0x7f4615ffe757 [ 593.241952] Code: 00 00 90 48 8b 05 39 a7 0c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 09 a7 0c 00 f7 d8 64 89 01 48 [ 593.241970] RSP: 002b:00007ffc1030ddf8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [ 593.241984] RAX: ffffffffffffffda RBX: 00007ffc10324420 RCX: 00007f4615ffe757 [ 593.241997] RDX: 00007ffc1030e220 RSI: 0000000040406469 RDI: 0000000000000003 [ 593.242010] RBP: 00007ffc1030e220 R08: 00007f46160c9208 R09: 00007f46160c9240 [ 593.242022] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000040406469 [ 593.242038] R13: 0000000000000003 R14: 0000000000000000 R15: 0000000000000000 [ 593.242058] Modules linked in: i915 intel_gtt drm_kms_helper prime_numbers v2: Track the local engine cache and explicitly clear it when switching engine locks. Fixes: a02eb975 ("drm/i915/execlists: Cache the priolist when rescheduling") Testcase: igt/gem_exec_whisper/contexts-priority # rare! Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Michał Winiarski <michal.winiarski@intel.com> Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190211204647.26723-1-chris@chris-wilson.co.uk (cherry picked from commit ed7dc677) Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
-
由 Chris Wilson 提交于
If we allocate while iterating the rbtree of active nodes, we may hit the shrinker and so retire the i915_active, reaping the rbtree. Modifying the rbtree as we iterate is not good behaviour, so acquire the i915_active first to keep the tree intact whenever we allocate. Fixes: a42375af ("drm/i915: Release the active tracker tree upon idling") Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190208134704.23039-1-chris@chris-wilson.co.ukReviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> (cherry picked from commit 312c4ba1) Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
-