[PATCH i-g-t] tests/intel/xe_fault_injection: Ignore all errors while injecting fault

[PATCH i-g-t] tests/intel/xe_fault_injection: Ignore all errors while injecting fault

[Satyanarayana K V P]

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@intel.com>
---
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Francois Dugast <francois.dugast@intel.com>
Cc: Jonathan Cavitt <jonathan.cavitt@intel.com>
Cc: John Harrison <John.C.Harrison@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(".*");
 }
 
 /*
@@ -234,7 +213,7 @@ inject_fault_probe(int fd, char pci_slot[], const char function_name[])
 	igt_info("Injecting error \"%s\" (%d) in function \"%s\"\n",
 		 strerror(-INJECT_ERRNO), INJECT_ERRNO, function_name);
 
-	ignore_faults_in_dmesg(function_name);
+	ignore_faults_in_dmesg();
 	injection_list_add(function_name);
 	set_retval(function_name, INJECT_ERRNO);
 
@@ -299,7 +278,7 @@ exec_queue_create_fail(int fd, struct drm_xe_engine_class_instance *instance,
 	igt_assert_eq(__xe_exec_queue_create(fd, vm, 1, 1, instance, 0, &exec_queue_id), 0);
 	xe_exec_queue_destroy(fd, exec_queue_id);
 
-	ignore_faults_in_dmesg(function_name);
+	ignore_faults_in_dmesg();
 	injection_list_add(function_name);
 	set_retval(function_name, INJECT_ERRNO);
 	igt_assert(__xe_exec_queue_create(fd, vm, 1, 1, instance, 0, &exec_queue_id) != 0);
@@ -334,7 +313,7 @@ vm_create_fail(int fd, const char function_name[], unsigned int flags)
 {
 	igt_assert_eq(simple_vm_create(fd, flags), 0);
 
-	ignore_faults_in_dmesg(function_name);
+	ignore_faults_in_dmesg();
 	injection_list_add(function_name);
 	set_retval(function_name, INJECT_ERRNO);
 	igt_assert(simple_vm_create(fd, flags) != 0);
@@ -397,7 +376,7 @@ vm_bind_fail(int fd, const char function_name[])
 
 	igt_assert_eq(simple_vm_bind(fd, vm), 0);
 
-	ignore_faults_in_dmesg(function_name);
+	ignore_faults_in_dmesg();
 	injection_list_add(function_name);
 	set_retval(function_name, INJECT_ERRNO);
 	igt_assert(simple_vm_bind(fd, vm) != 0);
@@ -445,7 +424,7 @@ oa_add_config_fail(int fd, int sysfs, int devid, const char function_name[])
 	igt_assert(igt_sysfs_scanf(sysfs, path, "%" PRIu64, &config_id) == 1);
 	igt_assert_eq(intel_xe_perf_ioctl(fd, DRM_XE_OBSERVATION_OP_REMOVE_CONFIG, &config_id), 0);
 
-	ignore_faults_in_dmesg(function_name);
+	ignore_faults_in_dmesg();
 	injection_list_add(function_name);
 	set_retval(function_name, INJECT_ERRNO);
 	igt_assert_lt(intel_xe_perf_ioctl(fd, DRM_XE_OBSERVATION_OP_ADD_CONFIG, &config), 0);
-- 
2.43.0

RE: [PATCH i-g-t] tests/intel/xe_fault_injection: Ignore all errors while injecting fault

[Cavitt, Jonathan]

-----Original Message-----
From: K V P, Satyanarayana <satyanarayana.k.v.p@intel.com> 
Sent: Thursday, May 29, 2025 6:32 AM
To: igt-dev@lists.freedesktop.org
Cc: K V P, Satyanarayana <satyanarayana.k.v.p@intel.com>; Wajdeczko, Michal <Michal.Wajdeczko@intel.com>; Dugast, Francois <francois.dugast@intel.com>; Cavitt, Jonathan <jonathan.cavitt@intel.com>; Harrison, John C <john.c.harrison@intel.com>
Subject: [PATCH i-g-t] tests/intel/xe_fault_injection: Ignore all errors while injecting fault
> 
> 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@intel.com>

You can add my
Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com>
to this patch, but lets wait to see what everyone else has to say about
it before proceeding with a merge.
-Jonathan Cavitt

> ---
> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
> Cc: Francois Dugast <francois.dugast@intel.com>
> Cc: Jonathan Cavitt <jonathan.cavitt@intel.com>
> Cc: John Harrison <John.C.Harrison@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(".*");
>  }
>  
>  /*
> @@ -234,7 +213,7 @@ inject_fault_probe(int fd, char pci_slot[], const char function_name[])
>  	igt_info("Injecting error \"%s\" (%d) in function \"%s\"\n",
>  		 strerror(-INJECT_ERRNO), INJECT_ERRNO, function_name);
>  
> -	ignore_faults_in_dmesg(function_name);
> +	ignore_faults_in_dmesg();
>  	injection_list_add(function_name);
>  	set_retval(function_name, INJECT_ERRNO);
>  
> @@ -299,7 +278,7 @@ exec_queue_create_fail(int fd, struct drm_xe_engine_class_instance *instance,
>  	igt_assert_eq(__xe_exec_queue_create(fd, vm, 1, 1, instance, 0, &exec_queue_id), 0);
>  	xe_exec_queue_destroy(fd, exec_queue_id);
>  
> -	ignore_faults_in_dmesg(function_name);
> +	ignore_faults_in_dmesg();
>  	injection_list_add(function_name);
>  	set_retval(function_name, INJECT_ERRNO);
>  	igt_assert(__xe_exec_queue_create(fd, vm, 1, 1, instance, 0, &exec_queue_id) != 0);
> @@ -334,7 +313,7 @@ vm_create_fail(int fd, const char function_name[], unsigned int flags)
>  {
>  	igt_assert_eq(simple_vm_create(fd, flags), 0);
>  
> -	ignore_faults_in_dmesg(function_name);
> +	ignore_faults_in_dmesg();
>  	injection_list_add(function_name);
>  	set_retval(function_name, INJECT_ERRNO);
>  	igt_assert(simple_vm_create(fd, flags) != 0);
> @@ -397,7 +376,7 @@ vm_bind_fail(int fd, const char function_name[])
>  
>  	igt_assert_eq(simple_vm_bind(fd, vm), 0);
>  
> -	ignore_faults_in_dmesg(function_name);
> +	ignore_faults_in_dmesg();
>  	injection_list_add(function_name);
>  	set_retval(function_name, INJECT_ERRNO);
>  	igt_assert(simple_vm_bind(fd, vm) != 0);
> @@ -445,7 +424,7 @@ oa_add_config_fail(int fd, int sysfs, int devid, const char function_name[])
>  	igt_assert(igt_sysfs_scanf(sysfs, path, "%" PRIu64, &config_id) == 1);
>  	igt_assert_eq(intel_xe_perf_ioctl(fd, DRM_XE_OBSERVATION_OP_REMOVE_CONFIG, &config_id), 0);
>  
> -	ignore_faults_in_dmesg(function_name);
> +	ignore_faults_in_dmesg();
>  	injection_list_add(function_name);
>  	set_retval(function_name, INJECT_ERRNO);
>  	igt_assert_lt(intel_xe_perf_ioctl(fd, DRM_XE_OBSERVATION_OP_ADD_CONFIG, &config), 0);
> -- 
> 2.43.0
> 
> 

Re: [PATCH i-g-t] tests/intel/xe_fault_injection: Ignore all errors while injecting fault

[Daniele Ceraolo Spurio]

On 5/29/2025 6:31 AM, 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.

This would make the test almost meaningless. If the test finds an actual 
bug (i.e., an error we didn't expect), how would CI detect and report it 
if all errors are ignored? The only situations we would still fail on is 
when the kernel just dies.

Daniele

>
> Signed-off-by: Satyanarayana K V P <satyanarayana.k.v.p@intel.com>
> ---
> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
> Cc: Francois Dugast <francois.dugast@intel.com>
> Cc: Jonathan Cavitt <jonathan.cavitt@intel.com>
> Cc: John Harrison <John.C.Harrison@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(".*");
>   }
>   
>   /*
> @@ -234,7 +213,7 @@ inject_fault_probe(int fd, char pci_slot[], const char function_name[])
>   	igt_info("Injecting error \"%s\" (%d) in function \"%s\"\n",
>   		 strerror(-INJECT_ERRNO), INJECT_ERRNO, function_name);
>   
> -	ignore_faults_in_dmesg(function_name);
> +	ignore_faults_in_dmesg();
>   	injection_list_add(function_name);
>   	set_retval(function_name, INJECT_ERRNO);
>   
> @@ -299,7 +278,7 @@ exec_queue_create_fail(int fd, struct drm_xe_engine_class_instance *instance,
>   	igt_assert_eq(__xe_exec_queue_create(fd, vm, 1, 1, instance, 0, &exec_queue_id), 0);
>   	xe_exec_queue_destroy(fd, exec_queue_id);
>   
> -	ignore_faults_in_dmesg(function_name);
> +	ignore_faults_in_dmesg();
>   	injection_list_add(function_name);
>   	set_retval(function_name, INJECT_ERRNO);
>   	igt_assert(__xe_exec_queue_create(fd, vm, 1, 1, instance, 0, &exec_queue_id) != 0);
> @@ -334,7 +313,7 @@ vm_create_fail(int fd, const char function_name[], unsigned int flags)
>   {
>   	igt_assert_eq(simple_vm_create(fd, flags), 0);
>   
> -	ignore_faults_in_dmesg(function_name);
> +	ignore_faults_in_dmesg();
>   	injection_list_add(function_name);
>   	set_retval(function_name, INJECT_ERRNO);
>   	igt_assert(simple_vm_create(fd, flags) != 0);
> @@ -397,7 +376,7 @@ vm_bind_fail(int fd, const char function_name[])
>   
>   	igt_assert_eq(simple_vm_bind(fd, vm), 0);
>   
> -	ignore_faults_in_dmesg(function_name);
> +	ignore_faults_in_dmesg();
>   	injection_list_add(function_name);
>   	set_retval(function_name, INJECT_ERRNO);
>   	igt_assert(simple_vm_bind(fd, vm) != 0);
> @@ -445,7 +424,7 @@ oa_add_config_fail(int fd, int sysfs, int devid, const char function_name[])
>   	igt_assert(igt_sysfs_scanf(sysfs, path, "%" PRIu64, &config_id) == 1);
>   	igt_assert_eq(intel_xe_perf_ioctl(fd, DRM_XE_OBSERVATION_OP_REMOVE_CONFIG, &config_id), 0);
>   
> -	ignore_faults_in_dmesg(function_name);
> +	ignore_faults_in_dmesg();
>   	injection_list_add(function_name);
>   	set_retval(function_name, INJECT_ERRNO);
>   	igt_assert_lt(intel_xe_perf_ioctl(fd, DRM_XE_OBSERVATION_OP_ADD_CONFIG, &config), 0);

✗ Fi.CI.BUILD: failure for tests/intel/xe_fault_injection: Ignore all errors while injecting fault

[Patchwork]

== Series Details ==

Series: tests/intel/xe_fault_injection: Ignore all errors while injecting fault
URL   : https://patchwork.freedesktop.org/series/149644/
State : failure

== Summary ==

Applying: tests/intel/xe_fault_injection: Ignore all errors while injecting fault
Using index info to reconstruct a base tree...
M	tests/intel/xe_fault_injection.c
Falling back to patching base and 3-way merge...
Auto-merging tests/intel/xe_fault_injection.c
CONFLICT (content): Merge conflict in tests/intel/xe_fault_injection.c
Patch failed at 0001 tests/intel/xe_fault_injection: Ignore all errors while injecting fault
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

Re: [PATCH i-g-t] tests/intel/xe_fault_injection: Ignore all errors while injecting fault

[Michal Wajdeczko]

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@intel.com>
> ---
> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
> Cc: Francois Dugast <francois.dugast@intel.com>
> Cc: Jonathan Cavitt <jonathan.cavitt@intel.com>
> Cc: John Harrison <John.C.Harrison@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*

and we want to catch/report all warn/WARN/BUG without just relying on
taint (and WARN will also catch our xe_asserts)

Re: [PATCH i-g-t] tests/intel/xe_fault_injection: Ignore all errors while injecting fault

[Michal Wajdeczko]

On 29.05.2025 18:23, Daniele Ceraolo Spurio wrote:
> 
> 
> On 5/29/2025 6:31 AM, 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.
> 
> This would make the test almost meaningless. If the test finds an actual
> bug (i.e., an error we didn't expect), how would CI detect and report it

but how can you tell upfront, without actually running a test, which
error is expected and which is not?

> if all errors are ignored? The only situations we would still fail on is
> when the kernel just dies.

and that perfectly fins, sine we should look only for BUG and WARNs, as
it's quite natural and expected that once we inject an error, the driver
will likely fail to load or proceed, and/or may report some error
messages, or even try to silently recover, *but* it shouldn't ever crash

and that should be taken as a test goal, not that we look for specific
error messages that could be changed, omitted, replaced by the different
driver release or when running on different platform or function

Michal

> 
> Daniele
> 

RE: [PATCH i-g-t] tests/intel/xe_fault_injection: Ignore all errors while injecting fault

[Cavitt, Jonathan]

-----Original Message-----
From: Wajdeczko, Michal <Michal.Wajdeczko@intel.com> 
Sent: Thursday, May 29, 2025 1:14 PM
To: K V P, Satyanarayana <satyanarayana.k.v.p@intel.com>; igt-dev@lists.freedesktop.org; Ceraolo Spurio, Daniele <daniele.ceraolospurio@intel.com>
Cc: Dugast, Francois <francois.dugast@intel.com>; Cavitt, Jonathan <jonathan.cavitt@intel.com>; Harrison, John C <john.c.harrison@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@intel.com>
> > ---
> > Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
> > Cc: Francois Dugast <francois.dugast@intel.com>
> > Cc: Jonathan Cavitt <jonathan.cavitt@intel.com>
> > Cc: John Harrison <John.C.Harrison@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

> 
> 

Re: [PATCH i-g-t] tests/intel/xe_fault_injection: Ignore all errors while injecting fault

[Kamil Konieczny]

Hi Satyanarayana,
On 2025-05-29 at 19:01:32 +0530, 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@intel.com>
> ---

Please also add to discussion Rodrigo
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>

Regards,
Kamil

> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
> Cc: Francois Dugast <francois.dugast@intel.com>
> Cc: Jonathan Cavitt <jonathan.cavitt@intel.com>
> Cc: John Harrison <John.C.Harrison@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(".*");
>  }
>  
>  /*
> @@ -234,7 +213,7 @@ inject_fault_probe(int fd, char pci_slot[], const char function_name[])
>  	igt_info("Injecting error \"%s\" (%d) in function \"%s\"\n",
>  		 strerror(-INJECT_ERRNO), INJECT_ERRNO, function_name);
>  
> -	ignore_faults_in_dmesg(function_name);
> +	ignore_faults_in_dmesg();
>  	injection_list_add(function_name);
>  	set_retval(function_name, INJECT_ERRNO);
>  
> @@ -299,7 +278,7 @@ exec_queue_create_fail(int fd, struct drm_xe_engine_class_instance *instance,
>  	igt_assert_eq(__xe_exec_queue_create(fd, vm, 1, 1, instance, 0, &exec_queue_id), 0);
>  	xe_exec_queue_destroy(fd, exec_queue_id);
>  
> -	ignore_faults_in_dmesg(function_name);
> +	ignore_faults_in_dmesg();
>  	injection_list_add(function_name);
>  	set_retval(function_name, INJECT_ERRNO);
>  	igt_assert(__xe_exec_queue_create(fd, vm, 1, 1, instance, 0, &exec_queue_id) != 0);
> @@ -334,7 +313,7 @@ vm_create_fail(int fd, const char function_name[], unsigned int flags)
>  {
>  	igt_assert_eq(simple_vm_create(fd, flags), 0);
>  
> -	ignore_faults_in_dmesg(function_name);
> +	ignore_faults_in_dmesg();
>  	injection_list_add(function_name);
>  	set_retval(function_name, INJECT_ERRNO);
>  	igt_assert(simple_vm_create(fd, flags) != 0);
> @@ -397,7 +376,7 @@ vm_bind_fail(int fd, const char function_name[])
>  
>  	igt_assert_eq(simple_vm_bind(fd, vm), 0);
>  
> -	ignore_faults_in_dmesg(function_name);
> +	ignore_faults_in_dmesg();
>  	injection_list_add(function_name);
>  	set_retval(function_name, INJECT_ERRNO);
>  	igt_assert(simple_vm_bind(fd, vm) != 0);
> @@ -445,7 +424,7 @@ oa_add_config_fail(int fd, int sysfs, int devid, const char function_name[])
>  	igt_assert(igt_sysfs_scanf(sysfs, path, "%" PRIu64, &config_id) == 1);
>  	igt_assert_eq(intel_xe_perf_ioctl(fd, DRM_XE_OBSERVATION_OP_REMOVE_CONFIG, &config_id), 0);
>  
> -	ignore_faults_in_dmesg(function_name);
> +	ignore_faults_in_dmesg();
>  	injection_list_add(function_name);
>  	set_retval(function_name, INJECT_ERRNO);
>  	igt_assert_lt(intel_xe_perf_ioctl(fd, DRM_XE_OBSERVATION_OP_ADD_CONFIG, &config), 0);
> -- 
> 2.43.0
> 

Re: [PATCH i-g-t] tests/intel/xe_fault_injection: Ignore all errors while injecting fault

[Kamil Konieczny]

Hi Cavitt,,
On 2025-05-29 at 21:48:32 +0000, Cavitt, Jonathan wrote:
> -----Original Message-----
> From: Wajdeczko, Michal <Michal.Wajdeczko@intel.com> 
> Sent: Thursday, May 29, 2025 1:14 PM
> To: K V P, Satyanarayana <satyanarayana.k.v.p@intel.com>; igt-dev@lists.freedesktop.org; Ceraolo Spurio, Daniele <daniele.ceraolospurio@intel.com>
> Cc: Dugast, Francois <francois.dugast@intel.com>; Cavitt, Jonathan <jonathan.cavitt@intel.com>; Harrison, John C <john.c.harrison@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@intel.com>
> > > ---

+cc Rodrigo

> > > Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
> > > Cc: Francois Dugast <francois.dugast@intel.com>
> > > Cc: Jonathan Cavitt <jonathan.cavitt@intel.com>
> > > Cc: John Harrison <John.C.Harrison@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
> 
> > 
> > 

Re: [PATCH i-g-t] tests/intel/xe_fault_injection: Ignore all errors while injecting fault

[Michal Wajdeczko]

On 29.05.2025 23:48, Cavitt, Jonathan wrote:
> -----Original Message-----
> From: Wajdeczko, Michal <Michal.Wajdeczko@intel.com> 
> Sent: Thursday, May 29, 2025 1:14 PM
> To: K V P, Satyanarayana <satyanarayana.k.v.p@intel.com>; igt-dev@lists.freedesktop.org; Ceraolo Spurio, Daniele <daniele.ceraolospurio@intel.com>
> Cc: Dugast, Francois <francois.dugast@intel.com>; Cavitt, Jonathan <jonathan.cavitt@intel.com>; Harrison, John C <john.c.harrison@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@intel.com>
>>> ---
>>> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
>>> Cc: Francois Dugast <francois.dugast@intel.com>
>>> Cc: Jonathan Cavitt <jonathan.cavitt@intel.com>
>>> Cc: John Harrison <John.C.Harrison@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.

I would prefer regex to match as much as possible and thus include DUT
BDF to avoid filtering out too much

> 
>>
>> 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:

we don't expect any WARNs or BUGs so we do not want them to be filtered
out, but highlighted instead

> 
> igt_emit_ignore_dmesg_regex("^((?!ERROR|WARN|BUG).)*$");
> 
> Would either of these be more amenable, Michal?
> -Jonathan Cavitt
> 
>>
>>

RE: [PATCH i-g-t] tests/intel/xe_fault_injection: Ignore all errors while injecting fault

[Cavitt, Jonathan]

-----Original Message-----
From: Wajdeczko, Michal <Michal.Wajdeczko@intel.com> 
Sent: Monday, June 2, 2025 6:01 AM
To: Cavitt, Jonathan <jonathan.cavitt@intel.com>; K V P, Satyanarayana <satyanarayana.k.v.p@intel.com>; igt-dev@lists.freedesktop.org; Ceraolo Spurio, Daniele <daniele.ceraolospurio@intel.com>; Vivi, Rodrigo <rodrigo.vivi@intel.com>
Cc: Dugast, Francois <francois.dugast@intel.com>; Harrison, John C <john.c.harrison@intel.com>
Subject: Re: [PATCH i-g-t] tests/intel/xe_fault_injection: Ignore all errors while injecting fault
> On 29.05.2025 23:48, Cavitt, Jonathan wrote:
> > -----Original Message-----
> > From: Wajdeczko, Michal <Michal.Wajdeczko@intel.com> 
> > Sent: Thursday, May 29, 2025 1:14 PM
> > To: K V P, Satyanarayana <satyanarayana.k.v.p@intel.com>; igt-dev@lists.freedesktop.org; Ceraolo Spurio, Daniele <daniele.ceraolospurio@intel.com>
> > Cc: Dugast, Francois <francois.dugast@intel.com>; Cavitt, Jonathan <jonathan.cavitt@intel.com>; Harrison, John C <john.c.harrison@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@intel.com>
> >>> ---
> >>> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
> >>> Cc: Francois Dugast <francois.dugast@intel.com>
> >>> Cc: Jonathan Cavitt <jonathan.cavitt@intel.com>
> >>> Cc: John Harrison <John.C.Harrison@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.
> 
> I would prefer regex to match as much as possible and thus include DUT
> BDF to avoid filtering out too much

Uh... Okay.  I think the regex that filters out all errors except for ERROR, WARN,
BUG, and DUT BDF would look something like:

"^((?!ERROR|WARN|BUG|[0-9][0-9][0-9][0-9]:[0-9][0-9]:[0-9][0-9]\.[0-9]).)*$"

At this point, we might want to consider a constructor for the string:

"""
static void emit_inverted_ignore_dmesg_list(void)
{
	char regex[1024];
	char store[1024] = "";

	/* Store all errors we want to continue reporting in store */
	strcat(store, "ERROR");
	strcat(store, "|WARN");
	strcat(store, "|BUG");
	strcat(store, "|[0-9][0-9][0-9][0-9]:[0-9][0-9]:[0-9][0-9]\.[0-9]");

	/* Invert store list with regex and pass to igt_emit_ignore_dmesg_regex */
	snprintf(regex, 1024, "^((?!%s).)*$", store);
	igt_emit_ignore_dmesg_regex(regex);
}
"""

> 
> > 
> >>
> >> 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:
> 
> we don't expect any WARNs or BUGs so we do not want them to be filtered
> out, but highlighted instead

My apologies for the misunderstanding.  When I referred to "catching" the
WARN and BUG messages, I was referring to catching them "in CI", not
catching them "in the filter".  So, the below regex should filter out all dmesg
messages that do not contain ERROR, WARN, or BUG, as per what you were
looking for when you requested additions (or, I guess, subtractions?) to the
filter.
-Jonathan Cavitt

> 
> > 
> > igt_emit_ignore_dmesg_regex("^((?!ERROR|WARN|BUG).)*$");
> > 
> > Would either of these be more amenable, Michal?
> > -Jonathan Cavitt
> > 
> >>
> >>
> 
> 

Re: [PATCH i-g-t] tests/intel/xe_fault_injection: Ignore all errors while injecting fault

[Daniele Ceraolo Spurio]

On 5/29/2025 1:29 PM, Michal Wajdeczko wrote:
>
> On 29.05.2025 18:23, Daniele Ceraolo Spurio wrote:
>>
>> On 5/29/2025 6:31 AM, 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.
>> This would make the test almost meaningless. If the test finds an actual
>> bug (i.e., an error we didn't expect), how would CI detect and report it
> but how can you tell upfront, without actually running a test, which
> error is expected and which is not?
>
>> if all errors are ignored? The only situations we would still fail on is
>> when the kernel just dies.
> and that perfectly fins, sine we should look only for BUG and WARNs, as
> it's quite natural and expected that once we inject an error, the driver
> will likely fail to load or proceed, and/or may report some error
> messages, or even try to silently recover, *but* it shouldn't ever crash
>
> and that should be taken as a test goal, not that we look for specific
> error messages that could be changed, omitted, replaced by the different
> driver release or when running on different platform or function

The patch does not look for WARNs though, it ignores all errors with a 
"*" filter, even WARNs. I'm still not fully convinced about ignoring 
anything, but I can understand the POV of ignoring just messages with 
the "ERROR" tag, as suggested in the other replies. I'd be happy with 
that kind of solution.

Daniele

>
> Michal
>
>> Daniele
>>

RE: [PATCH i-g-t] tests/intel/xe_fault_injection: Ignore all errors while injecting fault

[Cavitt, Jonathan]

-----Original Message-----
From: Ceraolo Spurio, Daniele <daniele.ceraolospurio@intel.com> 
Sent: Monday, June 2, 2025 11:26 AM
To: Wajdeczko, Michal <Michal.Wajdeczko@intel.com>; K V P, Satyanarayana <satyanarayana.k.v.p@intel.com>; igt-dev@lists.freedesktop.org; De Marchi, Lucas <lucas.demarchi@intel.com>
Cc: Dugast, Francois <francois.dugast@intel.com>; Cavitt, Jonathan <jonathan.cavitt@intel.com>; Harrison, John C <john.c.harrison@intel.com>
Subject: Re: [PATCH i-g-t] tests/intel/xe_fault_injection: Ignore all errors while injecting fault
> 
> On 5/29/2025 1:29 PM, Michal Wajdeczko wrote:
> >
> > On 29.05.2025 18:23, Daniele Ceraolo Spurio wrote:
> >>
> >> On 5/29/2025 6:31 AM, 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.
> >> This would make the test almost meaningless. If the test finds an actual
> >> bug (i.e., an error we didn't expect), how would CI detect and report it
> > but how can you tell upfront, without actually running a test, which
> > error is expected and which is not?
> >
> >> if all errors are ignored? The only situations we would still fail on is
> >> when the kernel just dies.
> > and that perfectly fins, sine we should look only for BUG and WARNs, as
> > it's quite natural and expected that once we inject an error, the driver
> > will likely fail to load or proceed, and/or may report some error
> > messages, or even try to silently recover, *but* it shouldn't ever crash
> >
> > and that should be taken as a test goal, not that we look for specific
> > error messages that could be changed, omitted, replaced by the different
> > driver release or when running on different platform or function
> 
> The patch does not look for WARNs though, it ignores all errors with a 
> "*" filter, even WARNs. I'm still not fully convinced about ignoring 
> anything, but I can understand the POV of ignoring just messages with 
> the "ERROR" tag, as suggested in the other replies. I'd be happy with 
> that kind of solution.

Huh?  I thought the alignment was that we were to ignore all messages
that *don't* have the ERROR tag, not the other way around?
-Jonathan Cavitt

> 
> Daniele
> 
> >
> > Michal
> >
> >> Daniele
> >>
> 
> 

Re: [PATCH i-g-t] tests/intel/xe_fault_injection: Ignore all errors while injecting fault

[Daniele Ceraolo Spurio]

On 6/2/2025 11:30 AM, Cavitt, Jonathan wrote:
> -----Original Message-----
> From: Ceraolo Spurio, Daniele <daniele.ceraolospurio@intel.com>
> Sent: Monday, June 2, 2025 11:26 AM
> To: Wajdeczko, Michal <Michal.Wajdeczko@intel.com>; K V P, Satyanarayana <satyanarayana.k.v.p@intel.com>; igt-dev@lists.freedesktop.org; De Marchi, Lucas <lucas.demarchi@intel.com>
> Cc: Dugast, Francois <francois.dugast@intel.com>; Cavitt, Jonathan <jonathan.cavitt@intel.com>; Harrison, John C <john.c.harrison@intel.com>
> Subject: Re: [PATCH i-g-t] tests/intel/xe_fault_injection: Ignore all errors while injecting fault
>> On 5/29/2025 1:29 PM, Michal Wajdeczko wrote:
>>> On 29.05.2025 18:23, Daniele Ceraolo Spurio wrote:
>>>> On 5/29/2025 6:31 AM, 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.
>>>> This would make the test almost meaningless. If the test finds an actual
>>>> bug (i.e., an error we didn't expect), how would CI detect and report it
>>> but how can you tell upfront, without actually running a test, which
>>> error is expected and which is not?
>>>
>>>> if all errors are ignored? The only situations we would still fail on is
>>>> when the kernel just dies.
>>> and that perfectly fins, sine we should look only for BUG and WARNs, as
>>> it's quite natural and expected that once we inject an error, the driver
>>> will likely fail to load or proceed, and/or may report some error
>>> messages, or even try to silently recover, *but* it shouldn't ever crash
>>>
>>> and that should be taken as a test goal, not that we look for specific
>>> error messages that could be changed, omitted, replaced by the different
>>> driver release or when running on different platform or function
>> The patch does not look for WARNs though, it ignores all errors with a
>> "*" filter, even WARNs. I'm still not fully convinced about ignoring
>> anything, but I can understand the POV of ignoring just messages with
>> the "ERROR" tag, as suggested in the other replies. I'd be happy with
>> that kind of solution.
> Huh?  I thought the alignment was that we were to ignore all messages
> that *don't* have the ERROR tag, not the other way around?
> -Jonathan Cavitt

We are injecting an error, so some messages with the ERROR tag are 
expected and should be ignored. The question is whether we should ignore 
all of them or keep a list if expected ones and ignore just those ones.

We definitely can't ignore warnings or asserts, as those signal that 
something is going very wrong.

Daniele

>
>> Daniele
>>
>>> Michal
>>>
>>>> Daniele
>>>>
>>

RE: [PATCH i-g-t] tests/intel/xe_fault_injection: Ignore all errors while injecting fault

[Cavitt, Jonathan]

-----Original Message-----
From: Ceraolo Spurio, Daniele <daniele.ceraolospurio@intel.com> 
Sent: Monday, June 2, 2025 1:32 PM
To: Cavitt, Jonathan <jonathan.cavitt@intel.com>; Wajdeczko, Michal <Michal.Wajdeczko@intel.com>; K V P, Satyanarayana <satyanarayana.k.v.p@intel.com>; igt-dev@lists.freedesktop.org; De Marchi, Lucas <lucas.demarchi@intel.com>
Cc: Dugast, Francois <francois.dugast@intel.com>; Harrison, John C <john.c.harrison@intel.com>
Subject: Re: [PATCH i-g-t] tests/intel/xe_fault_injection: Ignore all errors while injecting fault
> 
> On 6/2/2025 11:30 AM, Cavitt, Jonathan wrote:
> > -----Original Message-----
> > From: Ceraolo Spurio, Daniele <daniele.ceraolospurio@intel.com>
> > Sent: Monday, June 2, 2025 11:26 AM
> > To: Wajdeczko, Michal <Michal.Wajdeczko@intel.com>; K V P, Satyanarayana <satyanarayana.k.v.p@intel.com>; igt-dev@lists.freedesktop.org; De Marchi, Lucas <lucas.demarchi@intel.com>
> > Cc: Dugast, Francois <francois.dugast@intel.com>; Cavitt, Jonathan <jonathan.cavitt@intel.com>; Harrison, John C <john.c.harrison@intel.com>
> > Subject: Re: [PATCH i-g-t] tests/intel/xe_fault_injection: Ignore all errors while injecting fault
> >> On 5/29/2025 1:29 PM, Michal Wajdeczko wrote:
> >>> On 29.05.2025 18:23, Daniele Ceraolo Spurio wrote:
> >>>> On 5/29/2025 6:31 AM, 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.
> >>>> This would make the test almost meaningless. If the test finds an actual
> >>>> bug (i.e., an error we didn't expect), how would CI detect and report it
> >>> but how can you tell upfront, without actually running a test, which
> >>> error is expected and which is not?
> >>>
> >>>> if all errors are ignored? The only situations we would still fail on is
> >>>> when the kernel just dies.
> >>> and that perfectly fins, sine we should look only for BUG and WARNs, as
> >>> it's quite natural and expected that once we inject an error, the driver
> >>> will likely fail to load or proceed, and/or may report some error
> >>> messages, or even try to silently recover, *but* it shouldn't ever crash
> >>>
> >>> and that should be taken as a test goal, not that we look for specific
> >>> error messages that could be changed, omitted, replaced by the different
> >>> driver release or when running on different platform or function
> >> The patch does not look for WARNs though, it ignores all errors with a
> >> "*" filter, even WARNs. I'm still not fully convinced about ignoring
> >> anything, but I can understand the POV of ignoring just messages with
> >> the "ERROR" tag, as suggested in the other replies. I'd be happy with
> >> that kind of solution.
> > Huh?  I thought the alignment was that we were to ignore all messages
> > that *don't* have the ERROR tag, not the other way around?
> > -Jonathan Cavitt
> 
> We are injecting an error, so some messages with the ERROR tag are 
> expected and should be ignored. The question is whether we should ignore 
> all of them or keep a list if expected ones and ignore just those ones.

Keeping a list of expected errors and ignoring just those ones is what the regex
does currently.  This chain of emails occurred because the list needed to be
expanded to suppress more expected errors, and that caused some concerns
among reviewers:

[PATCH i-g-t] tests/intel/xe_fault_injection: Ignore enable activity stats error

If keeping a list of expected errors is a better solution to this problem, then
the above patch could use some additional review notes.
-Jonathan Cavitt

> 
> We definitely can't ignore warnings or asserts, as those signal that 
> something is going very wrong.
> 
> Daniele
> 
> >
> >> Daniele
> >>
> >>> Michal
> >>>
> >>>> Daniele
> >>>>
> >>
> 
> 

Re: [PATCH i-g-t] tests/intel/xe_fault_injection: Ignore all errors while injecting fault

[Lucas De Marchi]

On Mon, Jun 02, 2025 at 01:31:40PM -0700, Daniele Ceraolo Spurio wrote:
>
>
>On 6/2/2025 11:30 AM, Cavitt, Jonathan wrote:
>>-----Original Message-----
>>From: Ceraolo Spurio, Daniele <daniele.ceraolospurio@intel.com>
>>Sent: Monday, June 2, 2025 11:26 AM
>>To: Wajdeczko, Michal <Michal.Wajdeczko@intel.com>; K V P, Satyanarayana <satyanarayana.k.v.p@intel.com>; igt-dev@lists.freedesktop.org; De Marchi, Lucas <lucas.demarchi@intel.com>
>>Cc: Dugast, Francois <francois.dugast@intel.com>; Cavitt, Jonathan <jonathan.cavitt@intel.com>; Harrison, John C <john.c.harrison@intel.com>
>>Subject: Re: [PATCH i-g-t] tests/intel/xe_fault_injection: Ignore all errors while injecting fault
>>>On 5/29/2025 1:29 PM, Michal Wajdeczko wrote:
>>>>On 29.05.2025 18:23, Daniele Ceraolo Spurio wrote:
>>>>>On 5/29/2025 6:31 AM, 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.
>>>>>This would make the test almost meaningless. If the test finds an actual
>>>>>bug (i.e., an error we didn't expect), how would CI detect and report it
>>>>but how can you tell upfront, without actually running a test, which
>>>>error is expected and which is not?
>>>>
>>>>>if all errors are ignored? The only situations we would still fail on is
>>>>>when the kernel just dies.
>>>>and that perfectly fins, sine we should look only for BUG and WARNs, as
>>>>it's quite natural and expected that once we inject an error, the driver
>>>>will likely fail to load or proceed, and/or may report some error
>>>>messages, or even try to silently recover, *but* it shouldn't ever crash
>>>>
>>>>and that should be taken as a test goal, not that we look for specific
>>>>error messages that could be changed, omitted, replaced by the different
>>>>driver release or when running on different platform or function
>>>The patch does not look for WARNs though, it ignores all errors with a
>>>"*" filter, even WARNs. I'm still not fully convinced about ignoring
>>>anything, but I can understand the POV of ignoring just messages with
>>>the "ERROR" tag, as suggested in the other replies. I'd be happy with
>>>that kind of solution.
>>Huh?  I thought the alignment was that we were to ignore all messages
>>that *don't* have the ERROR tag, not the other way around?
>>-Jonathan Cavitt
>
>We are injecting an error, so some messages with the ERROR tag are 
>expected and should be ignored. The question is whether we should 
>ignore all of them or keep a list if expected ones and ignore just 
>those ones.
>
>We definitely can't ignore warnings or asserts, as those signal that 
>something is going very wrong.

Agreed. I think ignoring all **errors** would be ok: we don't want to
babysit the error messages and draw conclusions from them. It leads to a
lot of maintenance and even the odd situation of a typo fix in an error
message being flagged as regression.

The warnings we can't have already taint the kernel. So checking for
kernel taint should be good enough and I think we already do that,
don't we?

Lucas De Marchi

>
>Daniele
>
>>
>>>Daniele
>>>
>>>>Michal
>>>>
>>>>>Daniele
>>>>>
>>>
>