1. 17 2月, 2017 1 次提交
  2. 15 2月, 2017 1 次提交
  3. 09 2月, 2017 1 次提交
  4. 08 2月, 2017 7 次提交
  5. 03 2月, 2017 2 次提交
  6. 01 2月, 2017 2 次提交
  7. 31 1月, 2017 8 次提交
    • M
      drm/atomic: Fix double free in drm_atomic_state_default_clear · 92c715fc
      Maarten Lankhorst 提交于
      drm_atomic_helper_page_flip and drm_atomic_ioctl set their own events
      in crtc_state->event. But when it's set the event is freed in 2 places.
      
      Solve this by only freeing the event in the atomic ioctl when it
      allocated its own event.
      
      This has been broken twice. The first time when the code was introduced,
      but only in the corner case when an event is allocated, but more crtc's
      were included by atomic check and then failing. This can mostly
      happen when you do an atomic modeset in i915 and the display clock is
      changed, which forces all crtc's to be included to the state.
      
      This has been broken worse by adding in-fences support, which caused
      the double free to be done unconditionally.
      
      [IGT] kms_rotation_crc: starting subtest primary-rotation-180
      =============================================================================
      BUG kmalloc-128 (Tainted: G     U         ): Object already free
      -----------------------------------------------------------------------------
      
      Disabling lock debugging due to kernel taint
      INFO: Allocated in drm_atomic_helper_setup_commit+0x285/0x2f0 [drm_kms_helper] age=0 cpu=3 pid=1529
       ___slab_alloc+0x308/0x3b0
       __slab_alloc+0xd/0x20
       kmem_cache_alloc_trace+0x92/0x1c0
       drm_atomic_helper_setup_commit+0x285/0x2f0 [drm_kms_helper]
       intel_atomic_commit+0x35/0x4f0 [i915]
       drm_atomic_commit+0x46/0x50 [drm]
       drm_mode_atomic_ioctl+0x7d4/0xab0 [drm]
       drm_ioctl+0x2b3/0x490 [drm]
       do_vfs_ioctl+0x69c/0x700
       SyS_ioctl+0x4e/0x80
       entry_SYSCALL_64_fastpath+0x13/0x94
      INFO: Freed in drm_event_cancel_free+0xa3/0xb0 [drm] age=0 cpu=3 pid=1529
       __slab_free+0x48/0x2e0
       kfree+0x159/0x1a0
       drm_event_cancel_free+0xa3/0xb0 [drm]
       drm_mode_atomic_ioctl+0x86d/0xab0 [drm]
       drm_ioctl+0x2b3/0x490 [drm]
       do_vfs_ioctl+0x69c/0x700
       SyS_ioctl+0x4e/0x80
       entry_SYSCALL_64_fastpath+0x13/0x94
      INFO: Slab 0xffffde1f0997b080 objects=17 used=2 fp=0xffff92fb65ec2578 flags=0x200000000008101
      INFO: Object 0xffff92fb65ec2578 @offset=1400 fp=0xffff92fb65ec2ae8
      
      Redzone ffff92fb65ec2570: bb bb bb bb bb bb bb bb                          ........
      Object ffff92fb65ec2578: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk
      Object ffff92fb65ec2588: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk
      Object ffff92fb65ec2598: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk
      Object ffff92fb65ec25a8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk
      Object ffff92fb65ec25b8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk
      Object ffff92fb65ec25c8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk
      Object ffff92fb65ec25d8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk
      Object ffff92fb65ec25e8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5  kkkkkkkkkkkkkkk.
      Redzone ffff92fb65ec25f8: bb bb bb bb bb bb bb bb                          ........
      Padding ffff92fb65ec2738: 5a 5a 5a 5a 5a 5a 5a 5a                          ZZZZZZZZ
      CPU: 3 PID: 180 Comm: kworker/3:2 Tainted: G    BU          4.10.0-rc6-patser+ #5039
      Hardware name:                  /NUC5PPYB, BIOS PYBSWCEL.86A.0031.2015.0601.1712 06/01/2015
      Workqueue: events intel_atomic_helper_free_state [i915]
      Call Trace:
       dump_stack+0x4d/0x6d
       print_trailer+0x20c/0x220
       free_debug_processing+0x1c6/0x330
       ? drm_atomic_state_default_clear+0xf7/0x1c0 [drm]
       __slab_free+0x48/0x2e0
       ? drm_atomic_state_default_clear+0xf7/0x1c0 [drm]
       kfree+0x159/0x1a0
       drm_atomic_state_default_clear+0xf7/0x1c0 [drm]
       ? drm_atomic_state_clear+0x30/0x30 [drm]
       intel_atomic_state_clear+0xd/0x20 [i915]
       drm_atomic_state_clear+0x1a/0x30 [drm]
       __drm_atomic_state_free+0x13/0x60 [drm]
       intel_atomic_helper_free_state+0x5d/0x70 [i915]
       process_one_work+0x260/0x4a0
       worker_thread+0x2d1/0x4f0
       kthread+0x127/0x130
       ? process_one_work+0x4a0/0x4a0
       ? kthread_stop+0x120/0x120
       ret_from_fork+0x29/0x40
      FIX kmalloc-128: Object at 0xffff92fb65ec2578 not freed
      
      Fixes: 3b24f7d6 ("drm/atomic: Add struct drm_crtc_commit to track async updates")
      Fixes: 96260142 ("drm/fence: add in-fences support")
      Cc: <stable@vger.kernel.org> # v4.8+
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Reviewed-by: NGustavo Padovan <gustavo.padovan@collabora.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: http://patchwork.freedesktop.org/patch/msgid/1485854725-27640-1-git-send-email-maarten.lankhorst@linux.intel.com
      92c715fc
    • B
      drm/nouveau/kms/nv50: request vblank events for commits that send completion events · 2b507893
      Ben Skeggs 提交于
      This somehow fixes an issue where sync-to-vblank longer works correctly
      after resume from suspend.
      
      From a HW perspective, we don't need the IRQs turned on to be able to
      detect flip completion, so it's assumed that this is required for the
      voodoo in the core DRM vblank core.
      Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
      2b507893
    • I
      drm/nouveau/nv1a,nv1f/disp: fix memory clock rate retrieval · 24bf7ae3
      Ilia Mirkin 提交于
      Based on the xf86-video-nv code, NFORCE (NV1A) and NFORCE2 (NV1F) have a
      different way of retrieving clocks. See the
      nv_hw.c:nForceUpdateArbitrationSettings function in the original code
      for how these clocks were accessed.
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54587
      Cc: stable@vger.kernel.org
      Signed-off-by: NIlia Mirkin <imirkin@alum.mit.edu>
      Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
      24bf7ae3
    • A
      drm/nouveau/disp/gt215: Fix HDA ELD handling (thus, HDMI audio) on gt215 · d347583a
      Alastair Bridgewater 提交于
      Store the ELD correctly, not just enough copies of the first byte
      to pad out the given ELD size.
      Signed-off-by: NAlastair Bridgewater <alastair.bridgewater@gmail.com>
      Fixes: 120b0c39 ("drm/nv50-/disp: audit and version SOR_HDA_ELD method")
      Cc: stable@vger.kernel.org # v3.17+
      Reviewed-by: NIlia Mirkin <imirkin@alum.mit.edu>
      Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
      d347583a
    • M
      drm/nouveau/nouveau/led: prevent compiling the led-code if nouveau=y and leds=m · d72498ca
      Martin Peres 提交于
      The proper fix would have been to select LEDS_CLASS but this can lead
      to a circular dependency, as found out by Arnd.
      
      This patch implements Arnd's suggestion instead, at the cost of some
      auto-magic for a fringe feature.
      Reported-by: NArnd Bergmann <arnd@arndb.de>
      Reported-by: Intel's 0-DAY
      Fixes: 8d021d71 ("drm/nouveau/drm/nouveau: add a LED driver for the NVIDIA logo")
      Signed-off-by: NMartin Peres <martin.peres@free.fr>
      Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
      d72498ca
    • B
      drm/nouveau/disp/mcp7x: disable dptmds workaround · 7dfee682
      Ben Skeggs 提交于
      The workaround appears to cause regressions on these boards, and from
      inspection of RM traces, NVIDIA don't appear to do it on them either.
      Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
      Tested-by: NRoy Spliet <nouveau@spliet.org>
      7dfee682
    • B
      c966b627
    • B
  8. 30 1月, 2017 3 次提交
    • D
      drm: Don't race connector registration · e6e7b48b
      Daniel Vetter 提交于
      I was under the misconception that the sysfs dev stuff can be fully
      set up, and then registered all in one step with device_add. That's
      true for properties and property groups, but not for parents and child
      devices. Those must be fully registered before you can register a
      child.
      
      Add a bit of tracking to make sure that asynchronous mst connector
      hotplugging gets this right. For consistency we rely upon the implicit
      barriers of the connector->mutex, which is taken anyway, to ensure
      that at least either the connector or device registration call will
      work out.
      
      Mildly tested since I can't reliably reproduce this on my mst box
      here.
      Reported-by: NDave Hansen <dave.hansen@intel.com>
      Cc: Dave Hansen <dave.hansen@intel.com>
      Acked-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1484237756-2720-1-git-send-email-daniel.vetter@ffwll.ch
      e6e7b48b
    • D
      drm: prevent double-(un)registration for connectors · 4e5b54f1
      Daniel Vetter 提交于
      If we're unlucky then the registration from a hotplugged connector
      might race with the final registration step on driver load. And since
      MST topology discover is asynchronous that's even somewhat likely.
      
      v2: Also update the kerneldoc for @registered!
      
      v3: Review from Chris:
      - Improve kerneldoc for late_register/early_unregister callbacks.
      - Use mutex_destroy.
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: NSean Paul <seanpaul@chromium.org>
      Reported-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20161218133545.2106-1-daniel.vetter@ffwll.ch
      (cherry picked from commit e73ab00e)
      4e5b54f1
    • L
      drm/i915: Check for NULL i915_vma in intel_unpin_fb_obj() · 39cb2c9a
      Linus Torvalds 提交于
      I've seen this trigger twice now, where the i915_gem_object_to_ggtt()
      call in intel_unpin_fb_obj() returns NULL, resulting in an oops
      immediately afterwards as the (inlined) call to i915_vma_unpin_fence()
      tries to dereference it.
      
      It seems to be some race condition where the object is going away at
      shutdown time, since both times happened when shutting down the X
      server.  The call chains were different:
      
       - VT ioctl(KDSETMODE, KD_TEXT):
      
          intel_cleanup_plane_fb+0x5b/0xa0 [i915]
          drm_atomic_helper_cleanup_planes+0x6f/0x90 [drm_kms_helper]
          intel_atomic_commit_tail+0x749/0xfe0 [i915]
          intel_atomic_commit+0x3cb/0x4f0 [i915]
          drm_atomic_commit+0x4b/0x50 [drm]
          restore_fbdev_mode+0x14c/0x2a0 [drm_kms_helper]
          drm_fb_helper_restore_fbdev_mode_unlocked+0x34/0x80 [drm_kms_helper]
          drm_fb_helper_set_par+0x2d/0x60 [drm_kms_helper]
          intel_fbdev_set_par+0x18/0x70 [i915]
          fb_set_var+0x236/0x460
          fbcon_blank+0x30f/0x350
          do_unblank_screen+0xd2/0x1a0
          vt_ioctl+0x507/0x12a0
          tty_ioctl+0x355/0xc30
          do_vfs_ioctl+0xa3/0x5e0
          SyS_ioctl+0x79/0x90
          entry_SYSCALL_64_fastpath+0x13/0x94
      
       - i915 unpin_work workqueue:
      
          intel_unpin_work_fn+0x58/0x140 [i915]
          process_one_work+0x1f1/0x480
          worker_thread+0x48/0x4d0
          kthread+0x101/0x140
      
      and this patch purely papers over the issue by adding a NULL pointer
      check and a WARN_ON_ONCE() to avoid the oops that would then generally
      make the machine unresponsive.
      
      Other callers of i915_gem_object_to_ggtt() seem to also check for the
      returned pointer being NULL and warn about it, so this clearly has
      happened before in other places.
      
      [ Reported it originally to the i915 developers on Jan 8, applying the
        ugly workaround on my own now after triggering the problem for the
        second time with no feedback.
      
        This is likely to be the same bug reported as
      
           https://bugs.freedesktop.org/show_bug.cgi?id=98829
           https://bugs.freedesktop.org/show_bug.cgi?id=99134
      
        which has a patch for the underlying problem, but it hasn't gotten to
        me, so I'm applying the workaround. ]
      
      Cc: Daniel Vetter <daniel.vetter@intel.com>
      Cc: Jani Nikula <jani.nikula@linux.intel.com>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Cc: Imre Deak <imre.deak@intel.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      39cb2c9a
  9. 27 1月, 2017 4 次提交
    • S
      drm/vmwgfx: Fix depth input into drm_mode_legacy_fb_format · 242ef5d4
      Sinclair Yeh 提交于
      Currently the pitch is passed in as depth.  This causes
      drm_mode_legacy_fb_format() to return the wrong pixel format.
      
      The wrong pixel format will be rejected by vmw_kms_new_framebuffer(),
      thus leaving par->set_fb to NULL.
      
      This eventually causes a crash in vmw_fb_setcolreg() when the code
      tries to dereference par->set_fb.
      Signed-off-by: NSinclair Yeh <syeh@vmware.com>
      Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com>
      242ef5d4
    • L
      drm/nouveau: Handle fbcon suspend/resume in seperate worker · 15266ae3
      Lyude Paul 提交于
      Resuming from RPM can happen while already holding
      dev->mode_config.mutex. This means we can't actually handle fbcon in
      any RPM resume workers, since restoring fbcon requires grabbing
      dev->mode_config.mutex again. So move the fbcon suspend/resume code into
      it's own worker, and rely on that instead to avoid deadlocking.
      
      This fixes more deadlocks for runtime suspending the GPU on the ThinkPad
      W541. Reproduction recipe:
      
       - Get a machine with both optimus and a nvidia card with connectors
         attached to it
       - Wait for the nvidia GPU to suspend
       - Attempt to manually reprobe any of the connectors on the nvidia GPU
         using sysfs
       - *deadlock*
      
      [airlied: use READ_ONCE to address Hans's comment]
      Signed-off-by: NLyude <lyude@redhat.com>
      Cc: Hans de Goede <hdegoede@redhat.com>
      Cc: Kilian Singer <kilian.singer@quantumtechnology.info>
      Cc: Lukas Wunner <lukas@wunner.de>
      Cc: David Airlie <airlied@redhat.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      15266ae3
    • L
      drm/nouveau: Don't enabling polling twice on runtime resume · cae9ff03
      Lyude Paul 提交于
      As it turns out, on cards that actually have CRTCs on them we're already
      calling drm_kms_helper_poll_enable(drm_dev) from
      nouveau_display_resume() before we call it in
      nouveau_pmops_runtime_resume(). This leads us to accidentally trying to
      enable polling twice, which results in a potential deadlock between the
      RPM locks and drm_dev->mode_config.mutex if we end up trying to enable
      polling the second time while output_poll_execute is running and holding
      the mode_config lock. As such, make sure we only enable polling in
      nouveau_pmops_runtime_resume() if we need to.
      
      This fixes hangs observed on the ThinkPad W541
      Signed-off-by: NLyude <lyude@redhat.com>
      Cc: Hans de Goede <hdegoede@redhat.com>
      Cc: Kilian Singer <kilian.singer@quantumtechnology.info>
      Cc: Lukas Wunner <lukas@wunner.de>
      Cc: David Airlie <airlied@redhat.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      cae9ff03
    • Y
      drm/ast: Fixed system hanged if disable P2A · 6c971c09
      Y.C. Chen 提交于
      The original ast driver will access some BMC configuration through P2A bridge
      that can be disabled since AST2300 and after.
      It will cause system hanged if P2A bridge is disabled.
      Here is the update to fix it.
      Signed-off-by: NY.C. Chen <yc_chen@aspeedtech.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      6c971c09
  10. 26 1月, 2017 2 次提交
  11. 25 1月, 2017 9 次提交