On Thu, 01 Feb 2018 16:28:31 +0100, Chris Wilson
<chris@xxxxxxxxxxxxxxxxxx> wrote:
Quoting Michal Wajdeczko (2018-02-01 14:47:05)
On Wed, 31 Jan 2018 21:48:42 +0100, Chris Wilson
<chris@xxxxxxxxxxxxxxxxxx> wrote:
> Quoting Michal Wajdeczko (2018-01-31 18:23:47)
>> Our inject_load_failure functionality allows to insert one
>> failure during driver load, but it is hard to guess which
>> number should passed as modparam to select specific checkpoint.
>>
>> Use negative number as option to list all available failure
>> checkpoints without triggering any failure.
>
> Hmm, it was only intended for use with the coupled igt test. Mind
> expanding upon the use case you have? Could you not use that iterative
> search for finding the injection value you want for repeated runs? For
> the bisect case, do you not want to keep it iterating over all in case
> the value changes? How stable do you want the modparam?
Iterative approach is good for validation team to verify that all
existing failure points are correctly handled (ie. we don't cause
crash/panic), but it is less useful when you are interested in adding
new checkpoints just for your code, as it requires both time and luck
as you may be hit by earlier checkpoint that no longer works ;)
Btw, IMHO this modparam should only be exposed in DEBUG config (as it
introduces some code and text), and maybe we should also consider
extending it to support more than one failure (as then it will be
easy to check several code paths (like failure in fallback)
Sure, let's get it under the IS_ENABLED(CONFIG_DRM_I915_DEBUG).
I'll send separate patch for this.
This patch was trying to keep definition of modparam unchanged (extra
-1 value should not be noticed by any existing use case) but since
it is purely debug feature I'm not against making bigger changes here.
From my pov, it's very useful to define how you expect it to work, and
I was assuming these steps:
1. add new failure checkpoint(s) to the code
2. boot driver with inject modparam=-1 to list active checkpoints
3. note the number of checkpoint that we want to trigger
4. boot driver with inject modparam=n to trigger selected checkpoint
5. repeat steps 2-4 in case of rebase/code refactor/new checkpoints
how to make it more useful than drv_module_reload and to keep it working
as you intend. A pure fault-counter doesn't seem very robust or
intuitive for me when you are trying to develop a new fault point. Otoh,
Currently we identify fault checkpoint by pair [function:line] so if we
want
to invest more in this mechanism we can change modparam to char* and then
check against function and line instead of the counter. Then no iteration
(or listing checkpoints) would be needed.
I don't mind if the developer has to fix all the earlier fails when
testing his (those fails are all our responsibility) -- or at least file
bugs so that awareness is raised.
Agree.
Michal
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
