1. 07 Jun, 2017 1 commit
    • Chris Wilson's avatar
      drm/i915: Short-circuit i915_gem_wait_for_idle() if already idle · e0da1963
      Chris Wilson authored
      If the device is asleep (no GT wakeref), we know the GPU is already idle.
      If we add an early return, we can avoid touching registers and checking
      hw state outside of the assumed GT wakelock. This prevents causing such
      errors whilst debugging:
      
      [ 2613.401647] RPM wakelock ref not held during HW access
      [ 2613.401684] ------------[ cut here ]------------
      [ 2613.401720] WARNING: CPU: 5 PID: 7739 at drivers/gpu/drm/i915/intel_drv.h:1787 gen6_read32+0x21f/0x2b0 [i915]
      [ 2613.401731] Modules linked in: snd_hda_intel i915 vgem snd_hda_codec_hdmi x86_pkg_temp_thermal intel_powerclamp snd_hda_codec_realtek coretemp snd_hda_codec_generic crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_codec snd_hwdep snd_hda_core snd_pcm r8169 mii mei_me lpc_ich mei prime_numbers [last unloaded: i915]
      [ 2613.401823] CPU: 5 PID: 7739 Comm: drv_missed_irq Tainted: G     U          4.12.0-rc2-CI-CI_DRM_421+ #1
      [ 2613.401825] Hardware name: MSI MS-7924/Z97M-G43(MS-7924), BIOS V1.12 02/15/2016
      [ 2613.401840] task: ffff880409e3a740 task.stack: ffffc900084dc000
      [ 2613.401861] RIP: 0010:gen6_read32+0x21f/0x2b0 [i915]
      [ 2613.401863] RSP: 0018:ffffc900084dfce8 EFLAGS: 00010292
      [ 2613.401869] RAX: 000000000000002a RBX: ffff8804016a8000 RCX: 0000000000000006
      [ 2613.401871] RDX: 0000000000000006 RSI: ffffffff81cbf2d9 RDI: ffffffff81c9e3a7
      [ 2613.401874] RBP: ffffc900084dfd18 R08: ffff880409e3afc8 R09: 0000000000000000
      [ 2613.401877] R10: 000000008a1c483f R11: 0000000000000000 R12: 000000000000209c
      [ 2613.401879] R13: 0000000000000001 R14: ffff8804016a8000 R15: ffff8804016ac150
      [ 2613.401882] FS:  00007f39ef3dd8c0(0000) GS:ffff88041fb40000(0000) knlGS:0000000000000000
      [ 2613.401885] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [ 2613.401887] CR2: 00000000023717c8 CR3: 00000002e7b34000 CR4: 00000000001406e0
      [ 2613.401889] Call Trace:
      [ 2613.401912]  intel_engine_is_idle+0x76/0x90 [i915]
      [ 2613.401931]  i915_gem_wait_for_idle+0xe6/0x1e0 [i915]
      [ 2613.401951]  fault_irq_set+0x40/0x90 [i915]
      [ 2613.401970]  i915_ring_test_irq_set+0x42/0x50 [i915]
      [ 2613.401976]  simple_attr_write+0xc7/0xe0
      [ 2613.401981]  full_proxy_write+0x4f/0x70
      [ 2613.401987]  __vfs_write+0x23/0x120
      [ 2613.401992]  ? rcu_read_lock_sched_held+0x75/0x80
      [ 2613.401996]  ? rcu_sync_lockdep_assert+0x2a/0x50
      [ 2613.401999]  ? __sb_start_write+0xfa/0x1f0
      [ 2613.402004]  vfs_write+0xc5/0x1d0
      [ 2613.402008]  ? trace_hardirqs_on_caller+0xe7/0x1c0
      [ 2613.402013]  SyS_write+0x44/0xb0
      [ 2613.402020]  entry_SYSCALL_64_fastpath+0x1c/0xb1
      [ 2613.402022] RIP: 0033:0x7f39eded6670
      [ 2613.402025] RSP: 002b:00007fffdcdcb1a8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
      [ 2613.402030] RAX: ffffffffffffffda RBX: ffffffff81470203 RCX: 00007f39eded6670
      [ 2613.402033] RDX: 0000000000000001 RSI: 000000000041bc33 RDI: 0000000000000006
      [ 2613.402036] RBP: ffffc900084dff88 R08: 00007f39ef3dd8c0 R09: 0000000000000001
      [ 2613.402038] R10: 0000000000000000 R11: 0000000000000246 R12: 000000000041bc33
      [ 2613.402041] R13: 0000000000000006 R14: 0000000000000000 R15: 0000000000000000
      [ 2613.402046]  ? __this_cpu_preempt_check+0x13/0x20
      [ 2613.402052] Code: 01 9b fa e0 0f ff e9 28 fe ff ff 80 3d 6a dd 0e 00 00 0f 85 29 fe ff ff 48 c7 c7 48 19 29 a0 c6 05 56 dd 0e 00 01 e8 da 9a fa e0 <0f> ff e9 0f fe ff ff b9 01 00 00 00 ba 01 00 00 00 44 89 e6 48
      [ 2613.402199] ---[ end trace 31f0cfa93ab632bf ]---
      
      Fixes: 25112b64 ("drm/i915: Wait for all engines to be idle as part of i915_gem_wait_for_idle()")
      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>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170530121334.17364-1-chris@chris-wilson.co.ukReviewed-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      (cherry picked from commit 863e9fde)
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      e0da1963
  2. 26 Apr, 2017 1 commit
  3. 18 Apr, 2017 1 commit
    • Paul E. McKenney's avatar
      mm: Rename SLAB_DESTROY_BY_RCU to SLAB_TYPESAFE_BY_RCU · 5f0d5a3a
      Paul E. McKenney authored
      A group of Linux kernel hackers reported chasing a bug that resulted
      from their assumption that SLAB_DESTROY_BY_RCU provided an existence
      guarantee, that is, that no block from such a slab would be reallocated
      during an RCU read-side critical section.  Of course, that is not the
      case.  Instead, SLAB_DESTROY_BY_RCU only prevents freeing of an entire
      slab of blocks.
      
      However, there is a phrase for this, namely "type safety".  This commit
      therefore renames SLAB_DESTROY_BY_RCU to SLAB_TYPESAFE_BY_RCU in order
      to avoid future instances of this sort of confusion.
      Signed-off-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Pekka Enberg <penberg@kernel.org>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: <linux-mm@kvack.org>
      Acked-by: default avatarJohannes Weiner <hannes@cmpxchg.org>
      Acked-by: default avatarVlastimil Babka <vbabka@suse.cz>
      [ paulmck: Add comments mentioning the old name, as requested by Eric
        Dumazet, in order to help people familiar with the old name find
        the new one. ]
      Acked-by: default avatarDavid Rientjes <rientjes@google.com>
      5f0d5a3a
  4. 11 Apr, 2017 1 commit
  5. 31 Mar, 2017 2 commits
  6. 30 Mar, 2017 3 commits
  7. 27 Mar, 2017 1 commit
    • Chris Wilson's avatar
      drm/i915: Check we have an wake device before flushing GTT writes · e2a2aa36
      Chris Wilson authored
      We can assume that if the device is asleep then all pending GTT writes
      will have been posted, and so we can defer the flush from
      i915_gem_object_flush_gtt_write_domain()
      
      [ 1957.462568] WARNING: CPU: 0 PID: 6132 at drivers/gpu/drm/i915/intel_drv.h:1742 fwtable_read32+0x123/0x150 [i915]
      [ 1957.462582] RPM wakelock ref not held during HW access
      [ 1957.462583] Modules linked in: i915 intel_gtt drm_kms_helper prime_numbers
      [ 1957.462607] CPU: 0 PID: 6132 Comm: gem_concurrent_ Tainted: G     U          4.11.0-rc1+ #464
      [ 1957.462619] Hardware name:                  /        , BIOS PYBSWCEL.86A.0027.2015.0507.1758 05/07/2015
      [ 1957.462630] Call Trace:
      [ 1957.462646]  dump_stack+0x4d/0x6f
      [ 1957.462657]  __warn+0xc1/0xe0
      [ 1957.462667]  warn_slowpath_fmt+0x4a/0x50
      [ 1957.462709]  fwtable_read32+0x123/0x150 [i915]
      [ 1957.462750]  i915_gem_object_flush_gtt_write_domain+0x43/0x70 [i915]
      [ 1957.462791]  i915_gem_object_set_to_cpu_domain+0x46/0xa0 [i915]
      [ 1957.462831]  i915_gem_set_domain_ioctl+0x15d/0x220 [i915]
      [ 1957.462843]  drm_ioctl+0x1d7/0x440
      [ 1957.462885]  ? i915_gem_obj_prepare_shmem_write+0x1d0/0x1d0 [i915]
      [ 1957.462896]  ? pick_next_task_fair+0x436/0x440
      [ 1957.462906]  ? mntput+0x1f/0x30
      [ 1957.462915]  do_vfs_ioctl+0x8f/0x5c0
      [ 1957.462925]  ? __schedule+0x16f/0x5f0
      [ 1957.462935]  ? ____fput+0x9/0x10
      [ 1957.462943]  SyS_ioctl+0x3c/0x70
      [ 1957.462952]  entry_SYSCALL_64_fastpath+0x17/0x98
      [ 1957.462961] RIP: 0033:0x7fc542179ca7
      [ 1957.462968] RSP: 002b:00007ffeef12ff98 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
      [ 1957.462982] RAX: ffffffffffffffda RBX: 00007ffeef1301d0 RCX: 00007fc542179ca7
      [ 1957.462990] RDX: 00007ffeef12ffd0 RSI: 00000000400c645f RDI: 0000000000000003
      [ 1957.462999] RBP: 0000000000000003 R08: 000055f433bc7c40 R09: 000000000000002c
      [ 1957.463006] R10: 0000000000000073 R11: 0000000000000246 R12: 0000000000000018
      [ 1957.463015] R13: 000055f432c89d20 R14: 000055f432c87690 R15: 0000000000000000
      
      Fixes: 3b5724d7 ("drm/i915: Wait for writes through the GTT to land before reading back")
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170323150053.28582-1-chris@chris-wilson.co.ukReviewed-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      e2a2aa36
  8. 23 Mar, 2017 2 commits
  9. 22 Mar, 2017 1 commit
  10. 20 Mar, 2017 1 commit
  11. 17 Mar, 2017 2 commits
  12. 16 Mar, 2017 2 commits
  13. 15 Mar, 2017 2 commits
    • Arkadiusz Hiler's avatar
      drm/i915/guc: Simplify intel_guc_init_hw() · 6cd5a72c
      Arkadiusz Hiler authored
      Current version of intel_guc_init_hw() does a lot:
       - cares about submission
       - loads huc
       - implement WA
      
      This change offloads some of the logic to intel_uc_init_hw(), which now
      cares about the above.
      
      v2: rename guc_hw_reset and fix typo in define name (M. Wajdeczko)
      v3: rename once again
      v4: remove spurious comments and add some style (J. Lahtinen)
      v5: flow changes, got rid of dead checks (M. Wajdeczko)
      v6: rebase
      v7: rebase & onion teardown (J. Lahtinen)
      
      Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
      Cc: Michal Winiarski <michal.winiarski@intel.com>
      Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
      Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Signed-off-by: default avatarArkadiusz Hiler <arkadiusz.hiler@intel.com>
      Reviewed-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Signed-off-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      6cd5a72c
    • Arkadiusz Hiler's avatar
      drm/i915/uc: Rename intel_?uc_{setup, load}() to _init_hw() · 882d1db0
      Arkadiusz Hiler authored
      GuC historically has two "startup" functions called _init() and _setup()
      
      Then HuC came with it's _init() and _load().
      
      This commit renames intel_guc_setup() and intel_huc_load() to
      *uc_init_hw() as they called from the i915_gem_init_hw().
      
      The aim is to be consistent in that entry points called during
      particular driver init phases (e.g. init_hw) are all suffixed by that
      phase. When reading the leaf functions, it should be clear at what stage
      during the driver load it is called and therefore what operations are
      legal at that point.
      
      Also, since the functions start with intel_guc and intel_huc they take
      appropiate structure.
      
      v2: commit message update (Chris Wilson)
      v3: change taken parameters to be more "semantic" (M. Wajdeczko)
      
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Michal Winiarski <michal.winiarski@intel.com>
      Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
      Signed-off-by: default avatarArkadiusz Hiler <arkadiusz.hiler@intel.com>
      Reviewed-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Signed-off-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      882d1db0
  14. 14 Mar, 2017 3 commits
  15. 13 Mar, 2017 1 commit
  16. 09 Mar, 2017 3 commits
  17. 08 Mar, 2017 1 commit
    • Chris Wilson's avatar
      drm/i915: Avoiding recursing on ww_mutex inside shrinker · 03d1cac6
      Chris Wilson authored
      We have to avoid taking ww_mutex inside the shrinker as we use it as a
      plain mutex type and so need to avoid recursive deadlocks:
      
      [  602.771969] =================================
      [  602.771970] [ INFO: inconsistent lock state ]
      [  602.771973] 4.10.0gpudebug+ #122 Not tainted
      [  602.771974] ---------------------------------
      [  602.771975] inconsistent {RECLAIM_FS-ON-W} -> {IN-RECLAIM_FS-W} usage.
      [  602.771978] kswapd0/40 [HC0[0]:SC0[0]:HE1:SE1] takes:
      [  602.771979]  (reservation_ww_class_mutex){+.+.?.}, at: [<ffffffffa054680a>] i915_gem_object_wait+0x39a/0x410 [i915]
      [  602.772020] {RECLAIM_FS-ON-W} state was registered at:
      [  602.772024]   mark_held_locks+0x76/0x90
      [  602.772026]   lockdep_trace_alloc+0xb8/0xc0
      [  602.772028]   __kmalloc_track_caller+0x5d/0x130
      [  602.772031]   krealloc+0x89/0xb0
      [  602.772033]   reservation_object_reserve_shared+0xaf/0xd0
      [  602.772055]   i915_gem_do_execbuffer.isra.35+0x1413/0x18b0 [i915]
      [  602.772075]   i915_gem_execbuffer2+0x10e/0x1d0 [i915]
      [  602.772078]   drm_ioctl+0x291/0x480
      [  602.772079]   do_vfs_ioctl+0x695/0x6f0
      [  602.772081]   SyS_ioctl+0x3c/0x70
      [  602.772084]   entry_SYSCALL_64_fastpath+0x18/0xad
      [  602.772085] irq event stamp: 5197423
      [  602.772088] hardirqs last  enabled at (5197423): [<ffffffff8116751d>] kfree+0xdd/0x170
      [  602.772091] hardirqs last disabled at (5197422): [<ffffffff811674f9>] kfree+0xb9/0x170
      [  602.772095] softirqs last  enabled at (5190992): [<ffffffff8107bfe1>] __do_softirq+0x221/0x280
      [  602.772097] softirqs last disabled at (5190575): [<ffffffff8107c294>] irq_exit+0x64/0xc0
      [  602.772099]
                     other info that might help us debug this:
      [  602.772100]  Possible unsafe locking scenario:
      
      [  602.772101]        CPU0
      [  602.772101]        ----
      [  602.772102]   lock(reservation_ww_class_mutex);
      [  602.772104]   <Interrupt>
      [  602.772105]     lock(reservation_ww_class_mutex);
      [  602.772107]
                      *** DEADLOCK ***
      
      [  602.772109] 2 locks held by kswapd0/40:
      [  602.772110]  #0:  (shrinker_rwsem){++++..}, at: [<ffffffff811337b5>] shrink_slab.constprop.62+0x35/0x280
      [  602.772116]  #1:  (&dev->struct_mutex){+.+.+.}, at: [<ffffffffa0553957>] i915_gem_shrinker_lock+0x27/0x60 [i915]
      [  602.772141]
                     stack backtrace:
      [  602.772144] CPU: 2 PID: 40 Comm: kswapd0 Not tainted 4.10.0gpudebug+ #122
      [  602.772145] Hardware name: LENOVO 42433ZG/42433ZG, BIOS 8AET64WW (1.44 ) 07/26/2013
      [  602.772147] Call Trace:
      [  602.772151]  dump_stack+0x68/0xa1
      [  602.772153]  print_usage_bug+0x1d4/0x1f0
      [  602.772155]  mark_lock+0x390/0x530
      [  602.772157]  ? print_irq_inversion_bug+0x200/0x200
      [  602.772159]  __lock_acquire+0x405/0x1260
      [  602.772181]  ? i915_gem_object_wait+0x39a/0x410 [i915]
      [  602.772183]  lock_acquire+0x60/0x80
      [  602.772205]  ? i915_gem_object_wait+0x39a/0x410 [i915]
      [  602.772207]  mutex_lock_nested+0x69/0x760
      [  602.772229]  ? i915_gem_object_wait+0x39a/0x410 [i915]
      [  602.772231]  ? kfree+0xdd/0x170
      [  602.772253]  ? i915_gem_object_wait+0x163/0x410 [i915]
      [  602.772255]  ? trace_hardirqs_on_caller+0x18d/0x1c0
      [  602.772256]  ? trace_hardirqs_on+0xd/0x10
      [  602.772278]  i915_gem_object_wait+0x39a/0x410 [i915]
      [  602.772300]  i915_gem_object_unbind+0x5e/0x130 [i915]
      [  602.772323]  i915_gem_shrink+0x22d/0x3d0 [i915]
      [  602.772347]  i915_gem_shrinker_scan+0x3f/0x80 [i915]
      [  602.772349]  shrink_slab.constprop.62+0x1ad/0x280
      [  602.772352]  shrink_node+0x52/0x80
      [  602.772355]  kswapd+0x427/0x5c0
      [  602.772358]  kthread+0x122/0x130
      [  602.772360]  ? try_to_free_pages+0x270/0x270
      [  602.772362]  ? kthread_stop+0x70/0x70
      [  602.772365]  ret_from_fork+0x2e/0x40
      
      v2: Add commentary about the pruning being opportunistic
      Reported-by: default avatarJan Nordholz <jckn@gmx.net>
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99977#c10
      Fixes: e54ca977 ("drm/i915: Remove completed fences after a wait")
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: Matthew Auld <matthew.auld@intel.com>
      Reviewed-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170308132629.7987-1-chris@chris-wilson.co.uk
      03d1cac6
  18. 07 Mar, 2017 2 commits
  19. 03 Mar, 2017 1 commit
  20. 02 Mar, 2017 2 commits
    • Chris Wilson's avatar
      drm/i915: Drop spinlocks around adding to the client request list · c8659efa
      Chris Wilson authored
      Adding to the tail of the client request list as the only other user is
      in the throttle ioctl that iterates forwards over the list. It only
      needs protection against deletion of a request as it reads it, it simply
      won't see a new request added to the end of the list, or it would be too
      early and rejected. We can further reduce the number of spinlocks
      required when throttling by removing stale requests from the client_list
      as we throttle.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarMika Kuoppala <mika.kuoppala@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170302122525.19675-1-chris@chris-wilson.co.uk
      c8659efa
    • Chris Wilson's avatar
      drm/i915: Hold rpm during GEM suspend in driver unload/suspend · c998e8a0
      Chris Wilson authored
      i915_gem_suspend() tries to access the device to ensure it is idle and
      all writes from the device are flushed to memory. It assumed is already
      held the runtime pm wakeref, but we should explicitly acquire it for our
      access to be safe.
      
      [  619.926287] WARNING: CPU: 3 PID: 9353 at drivers/gpu/drm/i915/intel_drv.h:1750 gen6_write32+0x23e/0x2a0 [i915]
      [  619.926300] RPM wakelock ref not held during HW access
      [  619.926311] Modules linked in: vgem x86_pkg_temp_thermal intel_powerclamp snd_hda_codec_hdmi snd_hda_codec_generic snd_hda_codec coretemp snd_hwdep crct10dif_pclmul snd_hda_core crc32_pclmul snd_pcm mei_me mei lpc_ich ghash_clmulni_intel i915(-) sdhci_pci sdhci mmc_core e1000e ptp pps_core prime_numbers [last unloaded: snd_hda_intel]
      [  619.926578] CPU: 3 PID: 9353 Comm: drv_module_relo Tainted: G     U          4.10.0-CI-Trybot_609+ #1
      [  619.926585] Hardware name: LENOVO 42962WU/42962WU, BIOS 8DET56WW (1.26 ) 12/01/2011
      [  619.926592] Call Trace:
      [  619.926609]  dump_stack+0x67/0x92
      [  619.926625]  __warn+0xc6/0xe0
      [  619.926640]  warn_slowpath_fmt+0x4a/0x50
      [  619.926726]  gen6_write32+0x23e/0x2a0 [i915]
      [  619.926801]  gen6_mm_switch+0x38/0x70 [i915]
      [  619.926871]  i915_switch_context+0xec/0xa10 [i915]
      [  619.926942]  i915_gem_switch_to_kernel_context+0x13c/0x2b0 [i915]
      [  619.927019]  i915_gem_suspend+0x2b/0x180 [i915]
      [  619.927079]  i915_driver_unload+0x22/0x200 [i915]
      [  619.927093]  ? __this_cpu_preempt_check+0x13/0x20
      [  619.927105]  ? trace_hardirqs_on_caller+0xe7/0x200
      [  619.927118]  ? trace_hardirqs_on+0xd/0x10
      [  619.927128]  ? _raw_spin_unlock_irqrestore+0x3d/0x60
      [  619.927192]  i915_pci_remove+0x14/0x20 [i915]
      [  619.927205]  pci_device_remove+0x34/0xb0
      [  619.927219]  device_release_driver_internal+0x158/0x210
      [  619.927234]  driver_detach+0x3b/0x80
      [  619.927245]  bus_remove_driver+0x53/0xd0
      [  619.927256]  driver_unregister+0x27/0x50
      [  619.927267]  pci_unregister_driver+0x25/0xa0
      [  619.927351]  i915_exit+0x1a/0xb1a [i915]
      [  619.927362]  SyS_delete_module+0x193/0x1e0
      [  619.927378]  entry_SYSCALL_64_fastpath+0x1c/0xb1
      [  619.927386] RIP: 0033:0x7f82b46c5d37
      [  619.927393] RSP: 002b:00007ffdb6f610d8 EFLAGS: 00000246 ORIG_RAX: 00000000000000b0
      [  619.927408] RAX: ffffffffffffffda RBX: ffffffff81481ff3 RCX: 00007f82b46c5d37
      [  619.927415] RDX: 0000000000000001 RSI: 0000000000000800 RDI: 000000000224f558
      [  619.927422] RBP: ffffc90001187f88 R08: 0000000000000000 R09: 00007ffdb6f61100
      [  619.927428] R10: 000000000224f4e0 R11: 0000000000000246 R12: 0000000000000000
      [  619.927435] R13: 00007ffdb6f612b0 R14: 0000000000000000 R15: 0000000000000000
      [  619.927451]  ? __this_cpu_preempt_check+0x13/0x20
      
      or
      
      [  641.646590] WARNING: CPU: 1 PID: 8913 at drivers/gpu/drm/i915/intel_drv.h:1750 intel_runtime_pm_get_noresume+0x8b/0x90 [i915]
      [  641.646595] RPM wakelock ref not held during HW access
      [  641.646600] Modules linked in: vgem snd_hda_codec_hdmi snd_hda_codec_generic x86_pkg_temp_thermal intel_powerclamp coretemp snd_hda_codec snd_hwdep crct10dif_pclmul snd_hda_core crc32_pclmul ghash_clmulni_intel snd_pcm mei_me mei i915(-) r8169 mii prime_numbers i2c_hid [last unloaded: snd_hda_intel]
      [  641.646825] CPU: 1 PID: 8913 Comm: drv_module_relo Tainted: G     U          4.10.0-CI-Trybot_609+ #1
      [  641.646836] Hardware name: TOSHIBA SATELLITE P50-C/06F4                            , BIOS 1.20 10/08/2015
      [  641.646843] Call Trace:
      [  641.646857]  dump_stack+0x67/0x92
      [  641.646869]  __warn+0xc6/0xe0
      [  641.646880]  warn_slowpath_fmt+0x4a/0x50
      [  641.646893]  ? __this_cpu_preempt_check+0x13/0x20
      [  641.646904]  ? trace_hardirqs_on_caller+0xe7/0x200
      [  641.646957]  intel_runtime_pm_get_noresume+0x8b/0x90 [i915]
      [  641.647022]  __i915_add_request+0x423/0x540 [i915]
      [  641.647080]  i915_gem_switch_to_kernel_context+0x148/0x2b0 [i915]
      [  641.647145]  i915_gem_suspend+0x2b/0x180 [i915]
      [  641.647189]  i915_driver_unload+0x22/0x200 [i915]
      [  641.647200]  ? __this_cpu_preempt_check+0x13/0x20
      [  641.647210]  ? trace_hardirqs_on_caller+0xe7/0x200
      [  641.647220]  ? trace_hardirqs_on+0xd/0x10
      [  641.647231]  ? _raw_spin_unlock_irqrestore+0x3d/0x60
      [  641.647276]  i915_pci_remove+0x14/0x20 [i915]
      [  641.647293]  pci_device_remove+0x34/0xb0
      [  641.647307]  device_release_driver_internal+0x158/0x210
      [  641.647321]  driver_detach+0x3b/0x80
      [  641.647330]  bus_remove_driver+0x53/0xd0
      [  641.647338]  driver_unregister+0x27/0x50
      [  641.647348]  pci_unregister_driver+0x25/0xa0
      [  641.647415]  i915_exit+0x1a/0xb1a [i915]
      [  641.647429]  SyS_delete_module+0x193/0x1e0
      [  641.647444]  entry_SYSCALL_64_fastpath+0x1c/0xb1
      [  641.647453] RIP: 0033:0x7fc622bd2d37
      [  641.647463] RSP: 002b:00007ffff8ffb5c8 EFLAGS: 00000246 ORIG_RAX: 00000000000000b0
      [  641.647475] RAX: ffffffffffffffda RBX: ffffffff81481ff3 RCX: 00007fc622bd2d37
      [  641.647480] RDX: 0000000000000001 RSI: 0000000000000800 RDI: 0000000000d49118
      [  641.647485] RBP: ffffc90000997f88 R08: 0000000000000000 R09: 00007ffff8ffb5f0
      [  641.647491] R10: 0000000000d490a0 R11: 0000000000000246 R12: 0000000000000000
      [  641.647498] R13: 00007ffff8ffb7a0 R14: 0000000000000000 R15: 0000000000000000
      [  641.647510]  ? __this_cpu_preempt_check+0x13/0x20
      
      v2: Keep holding rpm until the end to cover i915_gem_sanitize() as well.
      
      Fixes: 5ab57c70 ("drm/i915: Flush logical context image out to memory upon suspend")
      Fixes: 1c777c5d ("drm/i915/hsw: Fix GPU hang during resume from S3-devices state")
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170302083029.19576-1-chris@chris-wilson.co.ukReviewed-by: default avatarImre Deak <imre.deak@intel.com>
      Cc: <stable@vger.kernel.org> # v4.9+
      c998e8a0
  21. 27 Feb, 2017 1 commit
    • Chris Wilson's avatar
      drm/i915: Delay disabling the user interrupt for breadcrumbs · 67b807a8
      Chris Wilson authored
      A significant cost in setting up a wait is the overhead of enabling the
      interrupt. As we disable the interrupt whenever the queue of waiters is
      empty, if we are frequently waiting on alternating batches, we end up
      re-enabling the interrupt on a frequent basis. We do want to disable the
      interrupt during normal operations as under high load it may add several
      thousand interrupts/s - we have been known in the past to occupy whole
      cores with our interrupt handler after accidentally leaving user
      interrupts enabled. As a compromise, leave the interrupt enabled until
      the next IRQ, or the system is idle. This gives a small window for a
      waiter to keep the interrupt active and not be delayed by having to
      re-enable the interrupt.
      
      v2: Restore hangcheck/missed-irq detection for continuations
      v3: Be more careful restoring the hangcheck timer after reset
      v4: Be more careful restoring the fake irq after reset (if required!)
      v5: Redo changes to intel_engine_wakeup()
      v6: Factor out __intel_engine_wakeup()
      v7: Improve commentary for declaring a missed wakeup
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
      Reviewed-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170227205850.2828-4-chris@chris-wilson.co.uk
      67b807a8
  22. 25 Feb, 2017 1 commit
  23. 24 Feb, 2017 1 commit
    • Kenneth Graunke's avatar
      drm/i915: Drop support for I915_EXEC_CONSTANTS_* execbuf parameters. · ef0f411f
      Kenneth Graunke authored
      This patch makes the I915_PARAM_HAS_EXEC_CONSTANTS getparam return 0
      (indicating the optional feature is not supported), and makes execbuf
      always return -EINVAL if the flags are used.
      
      Apparently, no userspace ever shipped which used this optional feature:
      I checked the git history of Mesa, xf86-video-intel, libva, and Beignet,
      and there were zero commits showing a use of these flags.  Kernel commit
      72bfa19c apparently introduced the feature prematurely.  According
      to Chris, the intention was to use this in cairo-drm, but "the use was
      broken for gen6", so I don't think it ever happened.
      
      'relative_constants_mode' has always been tracked per-device, but this
      has actually been wrong ever since hardware contexts were introduced, as
      the INSTPM register is saved (and automatically restored) as part of the
      render ring context. The software per-device value could therefore get
      out of sync with the hardware per-context value.  This meant that using
      them is actually unsafe: a client which tried to use them could damage
      the state of other clients, causing the GPU to interpret their BO
      offsets as absolute pointers, leading to bogus memory reads.
      
      These flags were also never ported to execlist mode, making them no-ops
      on Gen9+ (which requires execlists), and Gen8 in the default mode.
      
      On Gen8+, userspace can write these registers directly, achieving the
      same effect.  On Gen6-7.5, it likely makes sense to extend the command
      parser to support them.  I don't think anyone wants this on Gen4-5.
      
      Based on a patch by Dave Gordon.
      
      v3: Return -ENODEV for the getparam, as this is what we do for other
          obsolete features.  Suggested by Chris Wilson.
      
      Cc: stable@vger.kernel.org
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92448Signed-off-by: default avatarKenneth Graunke <kenneth@whitecape.org>
      Reviewed-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170215093446.21291-1-kenneth@whitecape.orgAcked-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      ef0f411f
  24. 23 Feb, 2017 1 commit
  25. 22 Feb, 2017 3 commits