Skip to content

L
linux
Switch branch/tag
  1. 28 Apr, 2017 28 commits
  3. 26 Apr, 2017 12 commits
    • Arnd Bergmann's avatar
      drm: mali-dp: use div_u64 for expensive 64-bit divisions · 763656d3
      Arnd Bergmann authored 
      On 32-bit machines, we can't divide 64-bit integers:

drivers/gpu/drm/arm/malidp_crtc.o: In function `malidp_crtc_atomic_check':
malidp_crtc.c:(.text.malidp_crtc_atomic_check+0x3c0): undefined reference to `__aeabi_uldivmod'
malidp_crtc.c:(.text.malidp_crtc_atomic_check+0x3dc): undefined reference to `__aeabi_uldivmod'

This calls the div_u64 function explicitly instead.

Fixes: 4cea4e9f6690 ("drm: mali-dp: Add plane upscaling support")
Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      763656d3
    • Chris Wilson's avatar
      drm/i915: Confirm the request is still active before adding it to the await · 88326ef0
      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: default avatarChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: default avatarMichał Winiarski <michal.winiarski@intel.com>
Reviewed-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170422081537.6468-1-chris@chris-wilson.co.uk
(cherry picked from commit ade0b0c9)
Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      88326ef0
    • Chris Wilson's avatar
      drm/i915: Avoid busy-spinning on VLV_GLTC_PW_STATUS mmio · 96dabe99
      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: default avatarChris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Tomi Sarvela <tomi.p.sarvela@intel.com>
Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170421135815.11897-1-chris@chris-wilson.co.ukTested-by: default avatarTomi Sarvela <tomi.p.sarvela@intel.com>
(cherry picked from commit 3dd14c04)
Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      96dabe99
    • Chris Wilson's avatar
      drm/i915/selftests: Allocate inode/file dynamically · b162d47e
      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: default avatarArnd Bergmann <arnd@arndb.de>
Fixes: 66d9cb5d ("drm/i915: Mock the GEM device for self-testing")
Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Acked-by: default avatarArnd Bergmann <arnd@arndb.de>
Link: http://patchwork.freedesktop.org/patch/msgid/20170419094143.16922-2-chris@chris-wilson.co.ukReviewed-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
(cherry picked from commit 2310b3c9)
Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      b162d47e
    • Mika Kuoppala's avatar
      drm/i915: Fix system hang with EI UP masked on Haswell · acf2dc22
      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: default avatarMika Kuoppala <mika.kuoppala@intel.com>
Acked-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1492082127-29007-1-git-send-email-mika.kuoppala@intel.com
(cherry picked from commit 3396a273)
Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      acf2dc22
    • Dan Carpenter's avatar
      drm/i915: checking for NULL instead of IS_ERR() in mock selftests · 5af9e672
      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: default avatarDan Carpenter <dan.carpenter@oracle.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170413195217.GA26108@mwandaReviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
(cherry picked from commit be02f755)
Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      5af9e672
    • Ville Syrjälä's avatar
      drm/i915: Perform link quality check unconditionally during long pulse · dea65593
      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: default avatarPalmer 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: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/20170412193017.21029-1-ville.syrjala@linux.intel.com
(cherry picked from commit 1a36147b)
Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      dea65593
    • Chris Wilson's avatar
      drm/i915: Fix use after free in lpe_audio_platdev_destroy() · dde7b00e
      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: default avatarChris Wilson <chris@chris-wilson.co.uk>
Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Cc: Jerome Anand <jerome.anand@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Takashi Iwai <tiwai@suse.de>
Link: http://patchwork.freedesktop.org/patch/msgid/20170412080251.30648-1-chris@chris-wilson.co.ukReviewed-by: default avatarTakashi Iwai <tiwai@suse.de>
Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
(cherry picked from commit 48ae8074)
Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      dde7b00e
    • Chris Wilson's avatar
      drm/i915: Use the right mapping_gfp_mask for final shmem allocation · bdb57b8d
      Chris Wilson authored 
      Many sightings report the greater prevalence of allocation failures.
This is all due to the incorrect use of mapping_gfp_constraint(), so
remove it in favour of just querying the mapping_gfp_mask() which are
the exact gfp_t we wanted in the first place.

We still do expect a higher chance of reporting ENOMEM, as that is the
intention of using __GFP_NORETRY -- to fail rather than oom after having
reclaimed from our bo caches, and having done a direct|kswapd reclaim
pass.
Reported-by: default avatarJason Ekstrand <jason.ekstrand@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100594
Fixes: 24f8e00a ("drm/i915: Prefer to report ENOMEM rather than incur the oom for gfx allocations")
Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170405221514.23251-1-chris@chris-wilson.co.ukReviewed-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
(cherry picked from commit b268d9fe)
Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      bdb57b8d
    • Ville Syrjälä's avatar
      drm/i915: Make legacy cursor updates more unsynced · 440df938
      Ville Syrjälä authored 
      We're clearing the legacy_cursor_update flag before calling
drm_atomic_helper_setup_commit() which means the helper will
wait for the flip to complete before cleaning up the framebuffers.
That's not what we want for the legacy cursor, so let's clear
the flag after setting up the commit.

Also toss in a FIXME about solving these problems in a nicer
way using the fabled vblank workers.

v2: Also unsync with legacy page flips

Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Uwe Kleine-König <uwe@kleine-koenig.org>
Cc: Rafael Ristovski <rafael.ristovski@gmail.com>
Fixes: a5509abd ("drm/i915: Fix legacy cursor vs. watermarks for ILK-BDW")
Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170329142123.5923-1-ville.syrjala@linux.intel.comReviewed-by: default avatarMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
(cherry picked from commit 89520304)
Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      440df938
    • Chris Wilson's avatar
      drm/i915: Apply a cond_resched() to the saturated signaler · d445aaaa
      Chris Wilson authored 
      If the engine is continually completing nops, we can saturate the
signaler and keep it working indefinitely. This angers the NMI watchdog!

A good example is to disable semaphores on snb and run igt/gem_exec_nop -
the parallel, multi-engine workloads are more than sufficient to hog the
CPU, preventing the system from even processing ICMP echo replies.

v2: Tvrtko dug into cond_resched() on x86 and found that it only
depended upon preempt_count and not tif_need_resched() - which means
that we would always call schedule() at that point.

Fixes: c81d4613 ("drm/i915: Convert trace-irq to the breadcrumb waiter")
Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170404120531.10737-1-chris@chris-wilson.co.ukReviewed-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
(cherry picked from commit a7980a64)
Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      d445aaaa
    • Chris Wilson's avatar
      drm/i915: Park the signaler before sleeping · 1676a2b3
      Chris Wilson authored 
      If the signal to park arrives before we sleep, then we need to check
kthread_should_park() before sleeping to avoid missing the signal.
Otherwise, if the signal arrives whilst we are processing completed
requests, we will reset the current->state back to TASK_INTERRUPTIBLE
and so miss the wakeup.

Fixes: fe3288b5 ("drm/i915: Park the breadcrumbs signaler across a GPU reset")
Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170403105124.8969-1-chris@chris-wilson.co.ukReviewed-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
(cherry picked from commit b1becb88)
Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      1676a2b3
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7