- 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:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Michał Winiarski <michal.winiarski@intel.com> Reviewed-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170422081537.6468-1-chris@chris-wilson.co.uk
-
- 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:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Suggested-by:
Michal Wajdeczko <michal.wajdeczko@intel.com> Fixes: 1d1a9774 ("drm/i915: Extend intel_wait_for_register_fw() with fast timeout") Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-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:
Mika Kuoppala <mika.kuoppala@intel.com> Acked-by:
-
Daniel Vetter authored
Signed-off-by:Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 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:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by:
-
- 12 Apr, 2017 17 commits
-
-
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:
-
Manasi Navare authored
Currently intel_dp_check_link_status() tries to retrain the link if Clock recovery or Channel EQ for any of the lanes indicated by intel_dp->lane_count is not set. However these values cached in intel_dp structure can be stale if link training has failed for these values during previous modeset. Or these values can get stale since we have now re read the DPCD registers or it can be 0 in case of connected boot case. This patch validates these values against the max link rate and max lane count values. This is absolutely required incase the common_rates or max lane count are now different due to link fallback. v2: * Include the FIXME commnet inside the function (Ville Syrjala) * Remove the redundant parenthesis (Ville Syrjala) v3 by Jani: * rebase on the DP refactoring series * rename intel_dp_link_params_is_valid to intel_dp_link_params_valid * minor stylistic changes v4: * Compare the link rate against max link rate not the common_rates since common_rates does not account for the lowered fallback link rate value. (Ville Syrjala) v5: * Fixed a warning for unused variable (Manasi) Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Reviewed-by:
-
Chris Wilson authored
igt_mmap_offset_exhaustion() selftest was using live requests to make an object busy, but we did not hold a runtime pm wakeref for submitting the requests. Acquire it to avoid triggering "RPM wakelock ref not held during HW access" warnings. Signed-off-by:
-
Chris Wilson authored
If we have a mock engine and it has no more requests in flight, report it as idle as there is no hardware to contradict us! Otherwise we attempt to query the hw that doesn't exist and find that the hw hasn't set its idle bit and we get upset. Signed-off-by:
-
Chris Wilson authored
Provide dummy function pointers for the mock device in case we do hit mmio during testing. v2: Use ASSIGN_READ/WRITE_MMIO_FUNCS macros Signed-off-by:
-
Chris Wilson authored
When discussing a new WC mmap, we based the interface upon the assumption that GTT was fully coherent. How naive! Commits 3b5724d7 ("drm/i915: Wait for writes through the GTT to land before reading back") and ed4596ea ("drm/i915/guc: WA to address the Ringbuffer coherency issue") demonstrate that writes through the GTT are indeed delayed and may be overtaken by direct WC access. To be safe, if userspace is mixing WC mmaps with other potential GTT access (pwrite, GTT mmaps) it should use set_domain(WC). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96563 Testcase: igt/gem_pwrite/small-gtt* Testcase: igt/drv_selftest/coherency Signed-off-by:
-
Chris Wilson authored
In the next patch, we will introduce a new cache domain for differentiating between GTT access and direct WC access. This will require us to include WC in our write_domain flushes. Rather than duplicate a third function, combine the existing two into one and flushing WC writes will then be automatically handled as well. v2: Be smarter and clearer by passing in the write domains to flush (Joonas) v3: One missed ~ in v2 conversion Signed-off-by:
-
Maarten Lankhorst authored
There is no need to acquire all locks here, doing a commit after forcing a modeset on the affected crtc is enough. Any other locks needed will be acquired as needed. Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1491312297-18673-1-git-send-email-maarten.lankhorst@linux.intel.comReviewed-by:
-
Maarten Lankhorst authored
This reverts commit ea49c9ac. mode_config.mutex was originally added to fix WARNs in connector functions, but now that atomic nonblocking modeset support is included, we will likely never hold any any lock at all. The WARN mentioned in commit bbf35e9d ("drm/i915: Pass atomic state to intel_audio_codec_enable, v2."), so it's safe to revert this now. Signed-off-by:
-
Maarten Lankhorst authored
No properties are supported, so just use the helper and reject everything. Signed-off-by:
-
Maarten Lankhorst authored
No properties are supported, so just use the helper and reject everything. Signed-off-by:
-
Maarten Lankhorst authored
MST doesn't support setting any properties, but it should still use the atomic helper for setting properties. Only path and tile properties are supported (read-only). Those are immutable, and handled by drm core. Signed-off-by:
-
Maarten Lankhorst authored
Those properties are not hooked up on MST and were ignored. Best not expose them at all. Without this the next patch fails to start on X.org, because the DP-MST properties could not be read. Signed-off-by:
-
Maarten Lankhorst authored
intel_tv has properties that are handled in the atomic core, but needs a modeset to update the properties inside the connector. The detect(), get_mode() and mode_valid() probe callbacks also depend on the connector state, which made this a good connector to convert first. It helped find all the issues when converting connectors to atomic. Because of these requirements, connector atomic_check() was added and connection_mutex is held during probing. The diffstat looks more favorable now. :) Changes since v1: - Add intel_encoder->swap_state to allow updating connector state. - Add intel_tv->format for detect_mode and mode_valid, updated on atomic commit. Changes since v2: - Fix typo in tv_choose_preferred modes function name. - Assignment of tv properties is done in core, so intel_tv only needs a atomic_check function. Thanks Ville! Changes since v3: - connection_mutex is now held in mode_valid() and get_modes(), this removes the need for caching parts of the connector_state. Changes since v4: - Use the new atomic connector check function. Signed-off-by:
-
Maarten Lankhorst authored
They have been unused since 2010, after the code for intel_tv_save/restore was removed in the below commit: commit 6443170f Author: Eric Anholt <eric@anholt.net> Date: Fri Apr 2 15:24:27 2010 -0700 drm/i915: Remove dead KMS encoder save/restore code. This was brought over from UMS, and used for a while until we decided that drm_helper_resume_force_mode was easier and more reliable, since it didn't require duplicating all the code deleted here. We just forgot to delete all that junk for a while. Reviewed-by:
-
Chris Wilson authored
We indirectly hold the runtime-pm for the intel_lrc_irq_handler() by virtue of dev_priv->gt.awake keeping a wakeref whilst the requests are busy. As this is not obvious from the code, add a comment. Signed-off-by:
-
Daniel Vetter authored
Maarten needs both the new connector->atomic_check hook and the connection_mutex locking changes in the probe helpers to be able to start merging the connector property conversion to atomic. Signed-off-by:
-
- 11 Apr, 2017 8 commits
-
-
Chris Wilson authored
Similar to commit 8490ae20 ("drm/i915: Suppress busy status for engines if wedged") we also want to report intel_engine_is_idle() as true as well as the main intel_engines_are_idle(), as we now check that the engines are idle when overwriting the HWS page. This is not true whilst we are setting the device as wedged, at least according to our bookkeeping, so we have to lie to ourselves! [ 383.588601] [drm:i915_reset [i915]] *ERROR* Failed to reset chip: -110 [ 383.588685] ------------[ cut here ]------------ [ 383.588755] WARNING: CPU: 0 PID: 12 at drivers/gpu/drm/i915/intel_engine_cs.c:226 intel_engine_init_global_seqno+0x222/0x290 [i915] [ 383.588757] WARN_ON(!intel_engine_is_idle(engine)) [ 383.588759] Modules linked in: ctr ccm snd_hda_codec_hdmi snd_hda_codec_conexant snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hda_core arc4 iwldvm mac80211 snd_pcm snd_hwdep snd_seq_midi snd_seq_midi_event rfcomm bnep snd_rawmidi intel_powerclamp coretemp dm_multipath iwlwifi crct10dif_pclmul snd_seq crc32_pclmul ghash_clmulni_intel btusb aesni_intel btrtl btbcm aes_x86_64 crypto_simd cryptd btintel snd_timer glue_helper bluetooth intel_ips snd_seq_device cfg80211 snd soundcore binfmt_misc mei_me mei dm_mirror dm_region_hash dm_log i915 intel_gtt i2c_algo_bit drm_kms_helper cfbfillrect syscopyarea cfbimgblt sysfillrect sysimgblt fb_sys_fops cfbcopyarea prime_numbers ahci libahci drm e1000e [ 383.588851] CPU: 0 PID: 12 Comm: migration/0 Not tainted 4.11.0-rc5+ #207 [ 383.588853] Hardware name: LENOVO 514328U/514328U, BIOS 6QET44WW (1.14 ) 04/20/2010 [ 383.588855] Call Trace: [ 383.588866] dump_stack+0x63/0x90 [ 383.588871] __warn+0xc7/0xf0 [ 383.588876] warn_slowpath_fmt+0x4a/0x50 [ 383.588883] ? set_next_entity+0x821/0x910 [ 383.588943] intel_engine_init_global_seqno+0x222/0x290 [i915] [ 383.588998] __i915_gem_set_wedged_BKL+0xa4/0x190 [i915] [ 383.589003] ? __switch_to+0x215/0x390 [ 383.589008] multi_cpu_stop+0xbb/0xe0 [ 383.589012] ? cpu_stop_queue_work+0x90/0x90 [ 383.589016] cpu_stopper_thread+0x82/0x110 [ 383.589021] smpboot_thread_fn+0x137/0x190 [ 383.589026] kthread+0xf7/0x130 [ 383.589030] ? sort_range+0x20/0x20 [ 383.589034] ? kthread_park+0x90/0x90 [ 383.589040] ret_from_fork+0x2c/0x40 Fixes: 2ca9faa5 ("drm/i915: Assert the engine is idle before overwiting the HWS") Signed-off-by:
-
Daniele Ceraolo Spurio authored
Technically speaking, the context size is per engine class, not per instance. v2: Add MISSING_CASE (Tvrtko) v3: Rebased v4: Restore the interface back to hiding the class lookup (Chris) Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Oscar Mateo <oscar.mateo@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1491905472-16189-1-git-send-email-oscar.mateo@intel.comReviewed-by:
-
Chris Wilson authored
In places, we assume that RCS exists. This has been true forever, but let us catch this failure during bringup by adding an explicit check that we do have an RCS engine. v2: Make use of HAS_ENGINE (Tvrtko) Signed-off-by:
-
Jani Nikula authored
Don't clobber intel_dp->sink_count with the raw value. Suggested-by:
-
Jani Nikula authored
This is what we have the readb and writeb variants for. Do some minor return value and variable cleanup while at it. Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Jani Nikula authored
Localize link_rate_index to the if block, and rename to just index to reduce indent. Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Jani Nikula authored
The source might not support as many lanes as the sink, or the link training might have failed at higher lane counts. Take these into account. Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Jani Nikula authored
These are the theoretical maximums common for source and sink. These are the maximums we should start with. They may be degraded in case of link training failures, and the dynamic link values are stored separately. Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
