All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Wilson <chris@chris-wilson.co.uk>
To: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH v3] drm/i915: Add fault injection support
Date: Wed, 16 Mar 2016 09:24:45 +0000	[thread overview]
Message-ID: <20160316092445.GB14143@nuc-i3427.alporthouse.com> (raw)
In-Reply-To: <1458119884.5777.2.camel@linux.intel.com>

On Wed, Mar 16, 2016 at 11:18:04AM +0200, Joonas Lahtinen wrote:
> On ti, 2016-03-15 at 14:14 +0000, Chris Wilson wrote:
> > On Tue, Mar 15, 2016 at 04:01:14PM +0200, Imre Deak wrote:
> > > 
> > > I'm not sure if you want to check all failure paths, I think for that
> > > the existing failslab etc. mechanisms are better suited. This new
> > > option would be used at relatively few well defined places. The option
> > > is a mask since Chris wanted the possibility to mix failures (which
> > > makes sense when injecting a non-fatal failure somewhere). If he
> > > doesn't insist on that possibility I can convert the mask option to a
> > > counter based one identifying a single failure spot instead as you
> > > suggest. Chris?
> > We can extend the counter mechanism by having multiple counters behind
> > i915.inject_load_failure (i.e. =gem:4,driver:10,modeset:1)
> 
> Now that there's a series to split down the init functions nicely, one
> could use the function names directly. By stripping parts of it if
> needed to shorten them.

That's nice. Advantage for using counters is that we can write a test to
iterate over the first thousand and have it run against future
faultpointers. Advantage for using names is that it is readable and
easily extensible.

What we could do for testing is record the available fault injection
points for debugfs and so have the tests automatically adjust (given a
working start point). Overkill?
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2016-03-16  9:24 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-11 23:15 [PATCH] drm/i915: Add fault injection support Imre Deak
2016-03-12  7:40 ` ✗ Fi.CI.BAT: failure for " Patchwork
2016-03-14  9:20 ` [PATCH v2] " Imre Deak
2016-03-14 14:59   ` [PATCH v3] " Imre Deak
2016-03-15  8:34     ` Joonas Lahtinen
2016-03-15  9:28       ` Chris Wilson
2016-03-15 13:17         ` Daniel Vetter
2016-03-15 14:08       ` Imre Deak
2016-03-15  8:56     ` Daniel Vetter
2016-03-15 14:01       ` Imre Deak
2016-03-15 14:14         ` Chris Wilson
2016-03-16  9:18           ` Joonas Lahtinen
2016-03-16  9:24             ` Chris Wilson [this message]
2016-03-16  9:43               ` Imre Deak
2016-03-16 10:04                 ` Chris Wilson
2016-03-16 10:17                   ` Imre Deak
2016-03-16 10:26                     ` Chris Wilson
2016-03-14 10:40 ` ✗ Fi.CI.BAT: failure for drm/i915: Add fault injection support (rev2) Patchwork
2016-03-14 14:40 ` ✗ Fi.CI.BAT: failure for drm/i915: Add fault injection support (rev3) Patchwork

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=20160316092445.GB14143@nuc-i3427.alporthouse.com \
    --to=chris@chris-wilson.co.uk \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=joonas.lahtinen@linux.intel.com \
    /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.