1. 07 Feb, 2018 6 commits
  2. 06 Feb, 2018 2 commits
  3. 05 Feb, 2018 14 commits
  4. 02 Feb, 2018 7 commits
  5. 01 Feb, 2018 6 commits
    • Imre Deak's avatar
      drm/i915/bxt, glk: Avoid long atomic poll during CDCLK change · 006bb4cc
      Imre Deak authored
      There is no requirement for doing the PCODE request polling atomically,
      so do that only for a short time switching to sleeping poll afterwards.
      The specification requires a 150usec timeout for the change notification,
      so let's use that for the atomic poll. Do the extra 2ms poll - needed as
      a workaround on BXT/GLK - in sleeping mode.
      
      v2:
      - rebase on v2 of patchset dropping the sandybridge_pcode_read/write
        refactoring (Chris)
      
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: default avatarImre Deak <imre.deak@intel.com>
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180130142939.17983-2-imre.deak@intel.com
      006bb4cc
    • Imre Deak's avatar
      drm/i915/bxt, glk: Increase PCODE timeouts during CDCLK freq changing · e76019a8
      Imre Deak authored
      Currently we see sporadic timeouts during CDCLK changing both on BXT and
      GLK as reported by the Bugzilla: ticket. It's easy to reproduce this by
      changing the frequency in a tight loop after blanking the display. The
      upper bound for the completion time is 800us based on my tests, so
      increase it from the current 500us to 2ms; with that I couldn't trigger
      the problem either on BXT or GLK.
      
      Note that timeouts happened during both the change notification and the
      voltage level setting PCODE request. (For the latter one BSpec doesn't
      require us to wait for completion before further HW programming.)
      
      This issue is similar to
      commit 2c7d0602 ("drm/i915/gen9: Fix PCODE polling during CDCLK
      change notification")
      but there the PCODE request does complete (as shown by the mbox
      busy flag), only the reply we get from PCODE indicates a failure.
      So there we keep resending the request until a success reply, here we
      just have to increase the timeout for the one PCODE request we send.
      
      v2:
      - s/snb_pcode_request/sandybridge_pcode_write_timeout/ (Ville)
      
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: <stable@vger.kernel.org> # v4.4+
      Acked-by: Chris Wilson <chris@chris-wilson.co.uk> (v1)
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103326Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: default avatarImre Deak <imre.deak@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180130142939.17983-1-imre.deak@intel.com
      e76019a8
    • Michal Wajdeczko's avatar
      drm/i915/guc: Don't try to create log runtime if there is no log · 28647b52
      Michal Wajdeczko authored
      In case of GuC initialization failure we may continue with driver
      load, but we wrongly assume that GuC is fully functional. This
      leads to the BUG as we attempt to access non-existing log vma.
      
      [26386.121085] BUG: unable to handle kernel NULL pointer dereference at 00000000000000a0
      [26386.121225] IP: guc_log_runtime_create+0x23/0xe0 [i915]
      [26386.121763] Call Trace:
      [26386.121870]  guc_log_late_setup+0xfd/0x140 [i915]
      [26386.121969]  i915_driver_load+0x7ab/0x1730 [i915]
      [26386.122069]  i915_pci_probe+0x2d/0x90 [i915]
      [26386.122089]  pci_device_probe+0x9c/0x120
      [26386.122107]  driver_probe_device+0x2a9/0x490
      [26386.122126]  __driver_attach+0xd9/0xe0
      [26386.122143]  ? driver_probe_device+0x490/0x490
      [26386.122158]  bus_for_each_dev+0x57/0x90
      [26386.122175]  bus_add_driver+0x1eb/0x260
      [26386.122190]  ? 0xffffffffa069a000
      [26386.122206]  driver_register+0x52/0xc0
      [26386.122220]  ? 0xffffffffa069a000
      [26386.122234]  do_one_initcall+0x39/0x170
      [26386.122252]  ? kmem_cache_alloc_trace+0x1fd/0x2e0
      [26386.122273]  do_init_module+0x56/0x1ec
      [26386.122289]  load_module+0x219e/0x2550
      [26386.122309]  ? vfs_read+0x121/0x140
      [26386.122331]  ? SyS_finit_module+0xa5/0xe0
      [26386.122346]  SyS_finit_module+0xa5/0xe0
      [26386.122371]  entry_SYSCALL_64_fastpath+0x22/0x8f
      Signed-off-by: default avatarMichal Wajdeczko <michal.wajdeczko@intel.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Michal Winiarski <michal.winiarski@intel.com>
      Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
      Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180131173241.19704-4-michal.wajdeczko@intel.comReviewed-by: default avatarSagar Arun Kamble <sagar.a.kamble@intel.com>
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      28647b52
    • Michal Wajdeczko's avatar
      drm/i915/guc: Don't forget to free GuC error log · bf67ce62
      Michal Wajdeczko authored
      We're freeing GuC error log in uc_fini_hw() that matches
      corresponding uc_init_hw() but we missed the point that this
      log object is copied on error path and in case of failure in
      uc_init_hw() we will leak this object as uc_fini_hw() is
      never called.
      
      If we free this log object as part of the late uC cleanup, where
      we also release other firmware objects, we can avoid this BUG:
      
      [70841.001413] BUG drm_i915_gem_object (Tainted: G     U  W       ): Objects remaining in drm_i915_gem_object on __kmem_cache_shutdown()
      [70841.001436] INFO: Slab 0x00000000c94e41af objects=21 used=1 fp=0x000000001d60c40a flags=0x8000000000008100
      
      [70841.001466] Call Trace:
      [70841.001471]  dump_stack+0x5e/0x8e
      [70841.001476]  slab_err+0x99/0xb0
      [70841.001483]  ? __slab_alloc.isra.24.constprop.29+0x62/0x70
      [70841.001491]  ? __kmalloc+0x1f5/0x320
      [70841.001497]  __kmem_cache_shutdown+0x18b/0x400
      [70841.001505]  shutdown_cache+0x13/0x1c0
      [70841.001511]  kmem_cache_destroy+0x1c2/0x240
      [70841.001517]  ? __mutex_unlock_slowpath+0x38/0x270
      [70841.001559]  i915_gem_load_cleanup+0xbc/0x130 [i915]
      [70841.001595]  i915_driver_cleanup_early+0x11/0x60 [i915]
      [70841.001630]  i915_driver_load+0x708/0x1720 [i915]
      [70841.001638]  ? trace_hardirqs_on_caller+0xe2/0x1c0
      [70841.001673]  i915_pci_probe+0x2d/0x90 [i915]
      [70841.001680]  pci_device_probe+0x9c/0x120
      [70841.001687]  driver_probe_device+0x2a9/0x490
      [70841.001694]  __driver_attach+0xd9/0xe0
      [70841.001700]  ? driver_probe_device+0x490/0x490
      [70841.001705]  bus_for_each_dev+0x57/0x90
      [70841.001712]  bus_add_driver+0x1eb/0x260
      [70841.001717]  ? 0xffffffffa0685000
      [70841.001723]  driver_register+0x52/0xc0
      [70841.001728]  ? 0xffffffffa0685000
      [70841.001733]  do_one_initcall+0x39/0x170
      [70841.001739]  ? rcu_read_lock_sched_held+0x6f/0x80
      [70841.001746]  ? kmem_cache_alloc_trace+0x27b/0x2e0
      [70841.001753]  do_init_module+0x56/0x1ec
      [70841.001759]  load_module+0x219e/0x2550
      [70841.001766]  ? vfs_read+0x121/0x140
      [70841.001774]  ? SyS_finit_module+0xa5/0xe0
      [70841.001779]  SyS_finit_module+0xa5/0xe0
      [70841.001788]  entry_SYSCALL_64_fastpath+0x22/0x8f
      
      [70841.001806] INFO: Object 0x00000000eab7ed96 @offset=6208
      [70841.001850] INFO: Allocated in i915_gem_object_create.part.32+0x1f/0x260 [i915] age=38 cpu=0 pid=2708
      [70841.001861] 	kmem_cache_alloc+0x23d/0x2d0
      [70841.001897] 	i915_gem_object_create.part.32+0x1f/0x260 [i915]
      [70841.001937] 	intel_guc_allocate_vma+0x15/0x100 [i915]
      [70841.001977] 	intel_guc_log_create+0x34/0x1c0 [i915]
      [70841.002014] 	intel_guc_init+0x5a/0x100 [i915]
      [70841.002051] 	intel_uc_init+0x3e/0xb0 [i915]
      [70841.002089] 	i915_gem_init+0x18e/0x540 [i915]
      [70841.002123] 	i915_driver_load+0xa7a/0x1720 [i915]
      [70841.002159] 	i915_pci_probe+0x2d/0x90 [i915]
      [70841.002165] 	pci_device_probe+0x9c/0x120
      [70841.002171] 	driver_probe_device+0x2a9/0x490
      [70841.002177] 	__driver_attach+0xd9/0xe0
      [70841.002182] 	bus_for_each_dev+0x57/0x90
      [70841.002188] 	bus_add_driver+0x1eb/0x260
      [70841.002193] 	driver_register+0x52/0xc0
      [70841.002198] 	do_one_initcall+0x39/0x170
      [70841.002462] kmem_cache_destroy drm_i915_gem_object: Slab cache still has objects
      
      [70841.002491] Call Trace:
      [70841.002497]  dump_stack+0x5e/0x8e
      [70841.002503]  kmem_cache_destroy+0x1e0/0x240
      [70841.002509]  ? __mutex_unlock_slowpath+0x38/0x270
      [70841.002551]  i915_gem_load_cleanup+0xbc/0x130 [i915]
      [70841.002586]  i915_driver_cleanup_early+0x11/0x60 [i915]
      [70841.002621]  i915_driver_load+0x708/0x1720 [i915]
      [70841.002629]  ? trace_hardirqs_on_caller+0xe2/0x1c0
      [70841.002664]  i915_pci_probe+0x2d/0x90 [i915]
      [70841.002671]  pci_device_probe+0x9c/0x120
      [70841.002678]  driver_probe_device+0x2a9/0x490
      [70841.002684]  __driver_attach+0xd9/0xe0
      [70841.002690]  ? driver_probe_device+0x490/0x490
      [70841.002696]  bus_for_each_dev+0x57/0x90
      [70841.002702]  bus_add_driver+0x1eb/0x260
      [70841.002708]  ? 0xffffffffa0685000
      [70841.002713]  driver_register+0x52/0xc0
      [70841.002719]  ? 0xffffffffa0685000
      [70841.002724]  do_one_initcall+0x39/0x170
      [70841.002731]  ? rcu_read_lock_sched_held+0x6f/0x80
      [70841.002737]  ? kmem_cache_alloc_trace+0x27b/0x2e0
      [70841.002745]  do_init_module+0x56/0x1ec
      [70841.002751]  load_module+0x219e/0x2550
      [70841.002758]  ? vfs_read+0x121/0x140
      [70841.002766]  ? SyS_finit_module+0xa5/0xe0
      [70841.002772]  SyS_finit_module+0xa5/0xe0
      [70841.002781]  entry_SYSCALL_64_fastpath+0x22/0x8f
      Signed-off-by: default avatarMichal Wajdeczko <michal.wajdeczko@intel.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com>
      Cc: Michal Winiarski <michal.winiarski@intel.com>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180131173241.19704-2-michal.wajdeczko@intel.comReviewed-by: default avatarSagar Arun Kamble <sagar.a.kamble@intel.com>
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      bf67ce62
    • Matthew Auld's avatar
      drm/i915/selftests: add missing gtt shrinker test · fe215c8b
      Matthew Auld authored
      Try to catch a bug we've seen in the wild where the shrinker purges the
      pd/pdp from under us while allocating our paging structures.
      
      References: https://bugs.freedesktop.org/show_bug.cgi?id=104773Signed-off-by: default avatarMatthew Auld <matthew.auld@intel.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180131191453.12676-1-matthew.auld@intel.comReviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180131214440.7141-2-chris@chris-wilson.co.uk
      fe215c8b
    • Chris Wilson's avatar
      drm/i915/ppgtt: Pin page directories before allocation · b715a2f0
      Chris Wilson authored
      Commit e2b763ca ("drm/i915: Remove bitmap tracking for used-pdpes")
      believed that because it did not insert its freshly allocated page
      directory into the pd tree, it was safe from the shrinker. I failed to
      heed the lesson learnt from commit dd19674b ("drm/i915: Remove bitmap
      tracking for used-ptes") that we need to pin all the levels in the tree
      before hitting the shrinker or else the shrinker may free an upper layer
      as we proceed to allocate the tree. Thus leaving dangling pointers
      everywhere and a GPF should we hit direct reclaim at just the wrong
      moment.
      
      CPU: 0 PID: 7374 Comm: chromium Tainted: P           O    4.14.13-1-ARCH #1
      Hardware name: Apple Inc. MacBookPro12,1/Mac-E43C1C25D4880AD6, BIOS MBP121.88Z.0167.B33.1706181928 06/18/2017
      task: ffff994f696c2c40 task.stack: ffffb1a789d4c000
      RIP: 0010:gen8_ppgtt_set_pde.isra.40+0x48/0x70 [i915]
      RSP: 0018:ffffb1a789d4f940 EFLAGS: 00010206
      RAX: 81c1788cc4f68138 RBX: ffff994f54db8000 RCX: ffff994f696c2c40
      RDX: 000000023bc73003 RSI: ffff994d598b6b80 RDI: ffff994f54db8000
      RBP: ffff994d598b6b80 R08: 0000000000000000 R09: 0000000000000000
      R10: ffffb1a789d4f550 R11: ffff994eaf3c3208 R12: 0000000000000027
      R13: 0000000000005000 R14: 0000000004e8f000 R15: ffff994f54dba000
      FS:  00007f585886aa00(0000) GS:ffff994faec00000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00000000004ac8e8 CR3: 00000002552c8004 CR4: 00000000003606f0
      Call Trace:
       gen8_ppgtt_alloc_pdp+0x178/0x320 [i915]
       gen8_ppgtt_alloc_4lvl+0x5f/0x150 [i915]
       ppgtt_bind_vma+0x30/0x70 [i915]
       i915_vma_bind+0x68/0xd0 [i915]
       __i915_vma_do_pin+0x2d6/0x3a0 [i915]
       eb_lookup_vmas+0x7a2/0xb50 [i915]
       i915_gem_do_execbuffer+0x4d7/0x10e0 [i915]
       ? sock_wfree+0x34/0x60
       ? unix_stream_read_generic+0x1f9/0x7e0
       ? import_iovec+0x37/0xd0
       ? i915_gem_execbuffer2+0x5d/0x390 [i915]
       i915_gem_execbuffer2+0x1b7/0x390 [i915]
       ? i915_gem_execbuffer+0x2d0/0x2d0 [i915]
       drm_ioctl_kernel+0x59/0xb0 [drm]
       drm_ioctl+0x2d5/0x370 [drm]
       ? i915_gem_execbuffer+0x2d0/0x2d0 [i915]
       ? __seccomp_filter+0x3b/0x260
       do_vfs_ioctl+0xa1/0x610
       ? syscall_trace_enter+0xdb/0x2b0
       SyS_ioctl+0x74/0x80
       do_syscall_64+0x55/0x110
       entry_SYSCALL64_slow_path+0x25/0x25
      RIP: 0033:0x7f584fa82d27
      RSP: 002b:00007ffee14a7828 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
      RAX: ffffffffffffffda RBX: 000003b0126a1030 RCX: 00007f584fa82d27
      RDX: 00007ffee14a7870 RSI: 0000000040406469 RDI: 0000000000000080
      RBP: 00007ffee14a7870 R08: 0000000000000002 R09: 0000000000000077
      R10: 00007f5839f2b780 R11: 0000000000000246 R12: 0000000040406469
      R13: 0000000000000080 R14: 00007f5842b00040 R15: 0000000000000000
      Code: 01 00 83 81 58 0a 00 00 01 48 2b 05 13 9d fd c9 48 c1 f8 06 48 c1 e0 0c 48 8d 04 d0 48 8b 56 08 48 03 05 0c 9d fd c9 48 83 ca 03 <48> 89 10 83 a9 58 0a 00 00 01 65 ff 0d 37 03 fb 3e 74 02 f3 c3
      RIP: gen8_ppgtt_set_pde.isra.40+0x48/0x70 [i915] RSP: ffffb1a789d4f940
      Reported-by: default avatarEric Blau <eblau@eblau.com>
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104773
      Fixes: e2b763ca ("drm/i915: Remove bitmap tracking for used-pdpes")
      References: dd19674b ("drm/i915: Remove bitmap tracking for used-ptes")
      Testcase: igt/drv_selftest/live_gtt (igt_ppgtt_shrink_boom)
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Matthew Auld <matthew.auld@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180131214440.7141-1-chris@chris-wilson.co.ukReviewed-by: default avatarMatthew Auld <matthew.auld@intel.com>
      b715a2f0
  6. 31 Jan, 2018 5 commits