[PATCH i-g-t] tests/intel/xe_fault_injection: Ignore all errors while injecting fault
Kamil Konieczny
kamil.konieczny at linux.intel.com
Fri May 30 17:39:36 UTC 2025
Hi Cavitt,,
On 2025-05-29 at 21:48:32 +0000, Cavitt, Jonathan wrote:
> -----Original Message-----
> From: Wajdeczko, Michal <Michal.Wajdeczko at intel.com>
> Sent: Thursday, May 29, 2025 1:14 PM
> To: K V P, Satyanarayana <satyanarayana.k.v.p at intel.com>; igt-dev at lists.freedesktop.org; Ceraolo Spurio, Daniele <daniele.ceraolospurio at intel.com>
> Cc: Dugast, Francois <francois.dugast at intel.com>; Cavitt, Jonathan <jonathan.cavitt at intel.com>; Harrison, John C <john.c.harrison at intel.com>
> Subject: Re: [PATCH i-g-t] tests/intel/xe_fault_injection: Ignore all errors while injecting fault
> > On 29.05.2025 15:31, Satyanarayana K V P wrote:
> > > Currently, numerous fault messages have been included in the dmesg ignore list,
> > > and this list continues to expand. Each time a new fault injection point is
> > > introduced or a new feature is activated, additional fault messages appear,
> > > making it cumbersome to manage the dmesg ignore list.
> > >
> > > This new patch automatically ignores all error messages from dmesg, eliminating
> > > the need to add or maintain a dmesg ignore message list.
> > >
> > > Signed-off-by: Satyanarayana K V P <satyanarayana.k.v.p at intel.com>
> > > ---
+cc Rodrigo
> > > Cc: Michal Wajdeczko <michal.wajdeczko at intel.com>
> > > Cc: Francois Dugast <francois.dugast at intel.com>
> > > Cc: Jonathan Cavitt <jonathan.cavitt at intel.com>
> > > Cc: John Harrison <John.C.Harrison at Intel.com>
> > > ---
> > > tests/intel/xe_fault_injection.c | 35 +++++++-------------------------
> > > 1 file changed, 7 insertions(+), 28 deletions(-)
> > >
> > > diff --git a/tests/intel/xe_fault_injection.c b/tests/intel/xe_fault_injection.c
> > > index f9bd5c761..0dffbe5da 100644
> > > --- a/tests/intel/xe_fault_injection.c
> > > +++ b/tests/intel/xe_fault_injection.c
> > > @@ -64,30 +64,9 @@ static int fail_function_open(void)
> > > return debugfs_fail_function_dir_fd;
> > > }
> > >
> > > -static bool function_is_part_of_guc(const char function_name[])
> > > +static void ignore_faults_in_dmesg(void)
> > > {
> > > - return strstr(function_name, "_guc_") != NULL ||
> > > - strstr(function_name, "_uc_") != NULL ||
> > > - strstr(function_name, "_wopcm_") != NULL;
> > > -}
> > > -
> > > -static void ignore_faults_in_dmesg(const char function_name[])
> > > -{
> > > - /* Driver probe is expected to fail in all cases, so ignore in igt_runner */
> > > - char regex[1024] = "probe with driver xe failed with error -12";
> > > -
> > > - /*
> > > - * If GuC module fault is injected, GuC is expected to fail,
> > > - * so also ignore GuC init failures in igt_runner.
> > > - */
> > > - if (function_is_part_of_guc(function_name)) {
> > > - strcat(regex, "|GT[0-9a-fA-F]*: GuC init failed with -ENOMEM");
> > > - strcat(regex, "|GT[0-9a-fA-F]*: Failed to initialize uC .-ENOMEM");
> > > - strcat(regex, "|GT[0-9a-fA-F]*: Failed to enable GuC CT .-ENOMEM");
> > > - strcat(regex, "|GT[0-9a-fA-F]*: GuC PC query task state failed: -ENOMEM");
> > > - }
> > > -
> > > - igt_emit_ignore_dmesg_regex(regex);
> > > + igt_emit_ignore_dmesg_regex(".*");
> >
> > that will filter out all messages, no?
> >
> > maybe we should look for KERN_ERR level messages
> >
> > if IGT can't filter by level then at least look for our errors:
> >
> > xe 0000:00:02.0 [drm] *ERROR*
> > xe ... [drm] *ERROR*
> > [drm] *ERROR*
> > *ERROR*
>
> The regex for that would probably look something like:
>
> igt_emit_ignore_dmesg_regex("^((?!ERROR).)*$");
>
> The above regex should filter out all CI warnings that don't contain errors.
>
> >
> > and we want to catch/report all warn/WARN/BUG without just relying on
> > taint (and WARN will also catch our xe_asserts)
>
> If you also want to catch WARNs and BUGs, then the filter would look
> more like:
>
> igt_emit_ignore_dmesg_regex("^((?!ERROR|WARN|BUG).)*$");
>
> Would either of these be more amenable, Michal?
> -Jonathan Cavitt
>
> >
> >
More information about the igt-dev
mailing list