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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox