Skip to content

L
linux
Switch branch/tag
  1. 11 Dec, 2013 1 commit
    • Daniel Vetter's avatar
      drm/i915: don't update the dri1 breadcrumb with modesetting · 6c719fac
      Daniel Vetter authored 
      The update is horribly racy since it doesn't protect at all against
concurrent closing of the master fd. And it can't really since that
requires us to grab a mutex.

Instead of jumping through hoops and offloading this to a worker
thread just block this bit of code for the modesetting driver.

Note that the race is fairly easy to hit since we call the breadcrumb
function for any interrupt. So the vblank interrupt (which usually
keeps going for a bit) is enough. But even if we'd block this and only
update the breadcrumb for user interrupts from the CS we could hit
this race with kms/gem userspace: If a non-master is waiting somewhere
(and hence has interrupts enabled) and the master closes its fd
(probably due to crashing).

v2: Add a code comment to explain why fixing this for real isn't
really worth it. Also improve the commit message a bit.

v3: Fix the spelling in the comment.
Reported-by: default avatarEugene Shatokhin <eugene.shatokhin@rosalab.ru>
Cc: Eugene Shatokhin <eugene.shatokhin@rosalab.ru>
Cc: stable@vger.kernel.org
Acked-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
Tested-by: default avatarEugene Shatokhin <eugene.shatokhin@rosalab.ru>
Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      6c719fac
  3. 10 Dec, 2013 1 commit
  5. 06 Dec, 2013 2 commits
    • Daniel Vetter's avatar
      drm/i915: Fix use-after-free in do_switch · acc240d4
      Daniel Vetter authored 
      So apparently under ridiculous amounts of memory pressure we can get
into trouble in do_switch when we try to move the old hw context
backing storage object onto the active lists.

With list debugging enabled that usually results in us chasing a
poisoned pointer - which means we've hit upon a vma that has been
removed from all lrus with list_del (and then deallocated, so it's a
real use-after free).

Ian Lister has done some great callchain chasing and noticed that we
can reenter do_switch:

i915_gem_do_execbuffer()

i915_switch_context()

do_switch()
   from = ring->last_context;
   i915_gem_object_pin()

      i915_gem_object_bind_to_gtt()
         ret = drm_mm_insert_node_in_range_generic();
         // If the above call fails then it will try i915_gem_evict_something()
         // If that fails it will call i915_gem_evict_everything() ...
	 i915_gem_evict_everything()
	    i915_gpu_idle()
	       i915_switch_context(DEFAULT_CONTEXT)

Like with everything else where the shrinker or eviction code can
invalidate pointers we need to reload relevant state.

Note that there's no need to recheck whether a context switch is still
required because:

- Doing a switch to the same context is harmless (besides wasting a
  bit of energy).

- This can only happen with the default context. But since that one's
  pinned we'll never call down into evict_everything under normal
  circumstances. Note that there's a little driver bringup fun
  involved namely that we could recourse into do_switch for the
  initial switch. Atm we're fine since we assign the context pointer
  only after the call to do_switch at driver load or resume time. And
  in the gpu reset case we skip the entire setup sequence (which might
  be a bug on its own, but definitely not this one here).

Cc'ing stable since apparently ChromeOS guys are seeing this in the
wild (and not just on artificial stress tests), see the reference.

Note that in upstream code doesn't calle evict_everything directly
from evict_something, that's an extension in this product branch. But
we can still hit upon this bug (and apparently we do, see the linked
backtraces). I've noticed this while trying to construct a testcase
for this bug and utterly failed to provoke it. It looks like we need
to driver the system squarly into the lowmem wall and provoke the
shrinker to evict the context object by doing the last-ditch
evict_everything call.

Aside: There's currently no means to get a badly-fragmenting hw
context object away from a bad spot in the upstream code. We should
fix this by at least adding some code to evict_something to handle hw
contexts.

References: https://code.google.com/p/chromium/issues/detail?id=248191Reported-by: default avatarIan Lister <ian.lister@intel.com>
Cc: Ian Lister <ian.lister@intel.com>
Cc: stable@vger.kernel.org
Cc: Ben Widawsky <benjamin.widawsky@intel.com>
Cc: Stéphane Marchesin <marcheu@chromium.org>
Cc: Bloomfield, Jon <jon.bloomfield@intel.com>
Tested-by: default avatarRafael Barbalho <rafael.barbalho@intel.com>
Reviewed-by: default avatarIan Lister <ian.lister@intel.com>
Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      acc240d4
    • Daniel Vetter's avatar
      drm/i915: fix pm init ordering · f742a552
      Daniel Vetter authored 
      Shovel a bit more of the the code into the setup function, and call
it earlier. Otherwise lockdep is unhappy since we cancel the delayed
resume work before it's initialized.

While at it also shovel the pc8 setup code into the same functions.
I wanted to also ditch the header declaration of the hws pc8 functions,
but for unfathomable reasons that stuff is in intel_display.c instead
of intel_pm.c.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71980Tested-by: default avatarGuo Jinxian <jinxianx.guo@intel.com>
Reviewed-by: default avatarDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      f742a552
  7. 04 Dec, 2013 1 commit
  9. 03 Dec, 2013 3 commits
    • Ville Syrjälä's avatar
      drm/i915: Skip clock checks on BDW · 5ae68b41
      Ville Syrjälä authored 
      We don't have clock state readout support for DDI, so skip the pipe
config clock checks on all DDI platforms.
Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: default avatarDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      5ae68b41
    • Chris Wilson's avatar
      drm/i915: Do not clobber config status after a forced restore of hw state · edd5b133
      Chris Wilson authored 
      We call intel_modeset_setup_hw_state() along two paths, driver
load/resume and after a lid event notification. During initialisation of
the driver, it is imperative that we reset the config state. This
correctly sets up the initial connector statuses and prepares the
hardware for a thorough probing. However, during a lid event, we only
want to undo the damage caused by the bios by resetting our last known
mode. In this cirumstance, we do not want to clobber our desired state.

In order to try and keep sanity between the config state and our own
tracking, do the drm_mode_config_reset() first along the load/resume
paths before reading out the hw state and apply any definite known
corrections.

v2: "As discussed on irc I don't think we should force the connector
state to anything here: Imo connector->status should reflect what we
believe to be the true output connection state, whereas connector->encoder
reflects whether this connector is wired up to a pipe. And since we no
longer reject modeset on disconnected connectors and never nuked the pipe
if the connector gets disconnected there's no reason for that - such policy
is userspace's job.

This regression has been introduced in

commit 2e938892
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Thu Oct 11 20:08:24 2012 +0200

    drm/i915/crt: explicitly set up HOTPLUG_BITS on resume"
so sayeth Daniel.
Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: stable@vger.kernel.org (v3.8 and later)
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      edd5b133
    • Ville Syrjälä's avatar
      drm/i915: Take modeset locks around intel_modeset_setup_hw_state() · 02747664
      Ville Syrjälä authored 
      Some lower level things get angry if we don't have modeset locks
during intel_modeset_setup_hw_state(). Actually the resume and
lid_notify codepaths alreday hold the locks, but the init codepath
doesn't, so fix that.

Note: This slipped through since we only disable pipes if the
plane/pipe linking doesn't match. Which is only relevant on older
gen3 mobile machines, if the BIOS fails to set up our preferred
linking.
Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
Cc: stable@vger.kernel.org
Tested-and-reported-by: default avatarPaul Bolle <pebolle@tiscali.nl>
[danvet: Add note now that I could confirm my theory with the log
files Paul Bolle provided.]
Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      02747664
  11. 29 Nov, 2013 4 commits
  13. 28 Nov, 2013 3 commits
  15. 27 Nov, 2013 2 commits
  17. 26 Nov, 2013 1 commit
  19. 25 Nov, 2013 1 commit
  21. 21 Nov, 2013 1 commit
  23. 20 Nov, 2013 1 commit
    • Daniel Vetter's avatar
      drm/i915: Fix gen3 self-refresh watermarks · f727b490
      Daniel Vetter authored 
      This regression has been introduced in

commit 4fe8590a
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Wed Sep 4 18:25:22 2013 +0300

    drm/i915: Use adjusted_mode appropriately when computing watermarks

I guess we should renable the enabled local variable into something a
notch more descriptive, but that's something for -next.

The effect on my i945gme netbook is pretty severe amounts of underruns
- usually the very first pixel gets used for the entire screeen.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      f727b490
  25. 19 Nov, 2013 3 commits
  27. 18 Nov, 2013 2 commits
  29. 17 Nov, 2013 1 commit
    • Daniel Vetter's avatar
      drm/i915: restore the early forcewake cleanup · ef46e0d2
      Daniel Vetter authored 
      Some BIOS just leak the forcewak bits, which we clean up.
Unfortunately this has been broken in

commit 521198a2
Author: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Date:   Fri Aug 23 16:52:30 2013 +0300

    drm/i915: sanitize forcewake registers on reset

To make this work both for resets and for BIOS takeover just add the
forcewake clearing call back to intel_uncore_early_sanitize.

We need to clear the forcewake in early sanitize so that the forcewak
dance in intel_uncore_init (to figure out whether we have mt or legacy
forcewake on ivb) works. That cleanup fits in nicely with the general
topic of early_sanitize to prepare for the very first mmio ops.

Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reported-by: default avatarJörg Otte <jrg.otte@gmail.com>
Cc: Jörg Otte <jrg.otte@gmail.com>
References: https://lkml.org/lkml/2013/11/16/40
Cc: stable@vger.kernel.org (for 3.12 only)
Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      ef46e0d2
  31. 16 Nov, 2013 1 commit
  33. 15 Nov, 2013 1 commit
    • Daniel Vetter's avatar
      drm/i915: flush cursors harder · b2ea8ef5
      Daniel Vetter authored 
      Apparently they need the same treatment as primary planes. This fixes
modesetting failures because of stuck cursors (!) on Thomas' i830M
machine.

I've figured while at it I'll also roll it out for the ivb 3 pipe
version of this function. I didn't do this for i845/i865 since Bspec
says the update mechanism works differently, and there's some
additional rules about what can be updated in which order.
Tested-by: default avatarThomas Richter <thor@math.tu-berlin.de>
Cc: stable@vger.kernel.org
Cc:  Thomas Richter <thor@math.tu-berlin.de>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      b2ea8ef5
  35. 14 Nov, 2013 3 commits
  37. 13 Nov, 2013 7 commits
  39. 11 Nov, 2013 1 commit
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7