From: Imre Deak <imre.deak@intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH v3 19/19] drm/i915: Add fault injection support
Date: Wed, 16 Mar 2016 14:47:57 +0200 [thread overview]
Message-ID: <1458132477.4473.15.camel@intel.com> (raw)
In-Reply-To: <20160316124400.GK14143@nuc-i3427.alporthouse.com>
On Wed, 2016-03-16 at 12:44 +0000, Chris Wilson wrote:
> On Wed, Mar 16, 2016 at 02:12:35PM +0200, Imre Deak wrote:
> > On Wed, 2016-03-16 at 12:00 +0000, Chris Wilson wrote:
> > > On Wed, Mar 16, 2016 at 01:39:08PM +0200, Imre Deak wrote:
> > > > Add support for forcing an error at selected places in the
> > > > driver.
> > > > As an
> > > > example add 4 options to fail during driver loading.
> > > >
> > > > Requested by Chris.
> > > >
> > > > v2:
> > > > - Add fault point for modeset initialization
> > > > - Print debug message when injecting an error
> > > > v3:
> > > > - Rename inject_fault to inject_load_failure, rename the
> > > > related
> > > > macros
> > > > and helper accordingly (Chris)
> > > > - Use a counter instead of a mask to identify the failure point
> > > > (Daniel)
> > > > - Mark the module option as _unsafe and keep i915_params
> > > > ordered
> > > > (Joonas)
> > >
> > > Now that you have something so simple to use, putting a failure
> > > point
> > > at
> > > the start and end of each init_func is trivial (to test the local
> > > unwind
> > > in each function as well as the global unwind).
> >
> > Ok can do this, but again preferably as a follow-up:
> > i915_load_modeset_init() has pre-existing issues, the last thing I
> > checked was some running work item that gets scheduled after we
> > removed
> > the module already (maybe the eDP VDD work). I'll track down that
> > and
> > try to clean up the rest of problems I see in
> > i915_load_modeset_init();
> > with those I could add the additional checkpoints you suggest.
>
> Should we expose the injection fault count so that we can automate
> repeating the module reload for the right number of cycles?
Yes, can add that.
--Imre
> -Chris
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2016-03-16 12:48 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-16 11:38 [PATCH v3 00/19] Split driver init step to phases Imre Deak
2016-03-16 11:38 ` [PATCH v3 01/19] Fix MCHBAR cleanup on the driver init error path Imre Deak
2016-03-16 11:38 ` [PATCH v3 02/19] drm/i915: Move load time PCH detect, DPIO, power domain SW init earlier Imre Deak
2016-03-16 11:38 ` [PATCH v3 03/19] drm/i915: Move load time IRQ " Imre Deak
2016-03-16 11:38 ` [PATCH v3 04/19] drm/i915: Move load time init of display/audio hooks earlier Imre Deak
2016-03-16 11:38 ` [PATCH v3 05/19] drm/i915: Move load time init of clock gating " Imre Deak
2016-03-16 11:38 ` [PATCH v3 06/19] drm/i915: Move load time runtime device info init earlier Imre Deak
2016-03-16 11:38 ` [PATCH v3 07/19] drm/i915: Move load time gem_load_init earlier Imre Deak
2016-03-16 11:57 ` Chris Wilson
2016-03-16 12:18 ` Imre Deak
2016-03-16 12:54 ` [PATCH v4 " Imre Deak
2016-03-16 11:38 ` [PATCH v3 08/19] drm/i915: Move load time runtime PM get later Imre Deak
2016-03-16 11:38 ` [PATCH v3 09/19] drm/i915: Move load time shrinker registration later Imre Deak
2016-03-16 11:38 ` [PATCH v3 10/19] drm/i915: Move load time audio component registration earlier Imre Deak
2016-03-16 11:39 ` [PATCH v3 11/19] drm/i915: Move unload time display power domain uninit later Imre Deak
2016-03-16 11:39 ` [PATCH v3 12/19] drm/i915: Move unload time GTT, MSI IRQ cleanup later Imre Deak
2016-03-16 11:39 ` [PATCH v3 13/19] drm/i915: Move unload time opregion unregistration earlier Imre Deak
2016-03-16 11:39 ` [PATCH v3 14/19] drm/i915: Split out load time early initialization Imre Deak
2016-03-16 11:39 ` [PATCH v3 15/19] drm/i915: Split out load time MMIO initialization Imre Deak
2016-03-16 11:39 ` [PATCH v3 16/19] drm/i915: Split out load time HW initialization Imre Deak
2016-03-16 11:39 ` [PATCH v3 17/19] drm/i915: Split out load time interface registration Imre Deak
2016-03-16 11:39 ` [PATCH v3 18/19] drm/i915: Fix power domain HW state cleanup on error path Imre Deak
2016-03-16 11:39 ` [PATCH v3 19/19] drm/i915: Add fault injection support Imre Deak
2016-03-16 12:00 ` Chris Wilson
2016-03-16 12:12 ` Imre Deak
2016-03-16 12:44 ` Chris Wilson
2016-03-16 12:47 ` Imre Deak [this message]
2016-03-16 17:31 ` [PATCH v4 " Imre Deak
2016-03-16 12:01 ` [PATCH v3 00/19] Split driver init step to phases Chris Wilson
2016-03-16 16:44 ` ✗ Fi.CI.BAT: failure for Split driver init step to phases (rev2) Patchwork
2016-03-17 11:32 ` ✗ Fi.CI.BAT: warning for Split driver init step to phases (rev3) Patchwork
2016-03-17 12:23 ` Imre Deak
2016-03-17 13:27 ` Imre Deak
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1458132477.4473.15.camel@intel.com \
--to=imre.deak@intel.com \
--cc=chris@chris-wilson.co.uk \
--cc=daniel.vetter@ffwll.ch \
--cc=intel-gfx@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.