* RE: [PATCH i-g-t] tests/intel/xe_fault_injection: Ignore all errors while injecting fault
2025-05-29 13:31 [PATCH i-g-t] tests/intel/xe_fault_injection: Ignore all errors while injecting fault Satyanarayana K V P
@ 2025-05-29 14:22 ` Cavitt, Jonathan
2025-05-29 16:23 ` Daniele Ceraolo Spurio
` (3 subsequent siblings)
4 siblings, 0 replies; 16+ messages in thread
From: Cavitt, Jonathan @ 2025-05-29 14:22 UTC (permalink / raw)
To: K V P, Satyanarayana, igt-dev@lists.freedesktop.org
Cc: Wajdeczko, Michal, Dugast, Francois, Harrison, John C,
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
>
>
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [PATCH i-g-t] tests/intel/xe_fault_injection: Ignore all errors while injecting fault
2025-05-29 13:31 [PATCH i-g-t] tests/intel/xe_fault_injection: Ignore all errors while injecting fault Satyanarayana K V P
2025-05-29 14:22 ` Cavitt, Jonathan
@ 2025-05-29 16:23 ` Daniele Ceraolo Spurio
2025-05-29 20:29 ` Michal Wajdeczko
2025-05-29 18:40 ` ✗ Fi.CI.BUILD: failure for " Patchwork
` (2 subsequent siblings)
4 siblings, 1 reply; 16+ messages in thread
From: Daniele Ceraolo Spurio @ 2025-05-29 16:23 UTC (permalink / raw)
To: Satyanarayana K V P, igt-dev
Cc: Michal Wajdeczko, Francois Dugast, Jonathan Cavitt, John Harrison
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);
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [PATCH i-g-t] tests/intel/xe_fault_injection: Ignore all errors while injecting fault
2025-05-29 16:23 ` Daniele Ceraolo Spurio
@ 2025-05-29 20:29 ` Michal Wajdeczko
2025-06-02 18:25 ` Daniele Ceraolo Spurio
0 siblings, 1 reply; 16+ messages in thread
From: Michal Wajdeczko @ 2025-05-29 20:29 UTC (permalink / raw)
To: Daniele Ceraolo Spurio, Satyanarayana K V P, igt-dev,
Lucas De Marchi
Cc: Francois Dugast, Jonathan Cavitt, John Harrison
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
>
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH i-g-t] tests/intel/xe_fault_injection: Ignore all errors while injecting fault
2025-05-29 20:29 ` Michal Wajdeczko
@ 2025-06-02 18:25 ` Daniele Ceraolo Spurio
2025-06-02 18:30 ` Cavitt, Jonathan
0 siblings, 1 reply; 16+ messages in thread
From: Daniele Ceraolo Spurio @ 2025-06-02 18:25 UTC (permalink / raw)
To: Michal Wajdeczko, Satyanarayana K V P, igt-dev, Lucas De Marchi
Cc: Francois Dugast, Jonathan Cavitt, John Harrison
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
>>
^ permalink raw reply [flat|nested] 16+ messages in thread
* RE: [PATCH i-g-t] tests/intel/xe_fault_injection: Ignore all errors while injecting fault
2025-06-02 18:25 ` Daniele Ceraolo Spurio
@ 2025-06-02 18:30 ` Cavitt, Jonathan
2025-06-02 20:31 ` Daniele Ceraolo Spurio
0 siblings, 1 reply; 16+ messages in thread
From: Cavitt, Jonathan @ 2025-06-02 18:30 UTC (permalink / raw)
To: Ceraolo Spurio, Daniele, Wajdeczko, Michal, K V P, Satyanarayana,
igt-dev@lists.freedesktop.org, De Marchi, Lucas
Cc: Dugast, Francois, Harrison, John C, 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
> >>
>
>
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH i-g-t] tests/intel/xe_fault_injection: Ignore all errors while injecting fault
2025-06-02 18:30 ` Cavitt, Jonathan
@ 2025-06-02 20:31 ` Daniele Ceraolo Spurio
2025-06-02 21:09 ` Cavitt, Jonathan
2025-06-02 21:31 ` Lucas De Marchi
0 siblings, 2 replies; 16+ messages in thread
From: Daniele Ceraolo Spurio @ 2025-06-02 20:31 UTC (permalink / raw)
To: Cavitt, Jonathan, Wajdeczko, Michal, K V P, Satyanarayana,
igt-dev@lists.freedesktop.org, De Marchi, Lucas
Cc: Dugast, Francois, Harrison, John C
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
>>>>
>>
^ permalink raw reply [flat|nested] 16+ messages in thread
* RE: [PATCH i-g-t] tests/intel/xe_fault_injection: Ignore all errors while injecting fault
2025-06-02 20:31 ` Daniele Ceraolo Spurio
@ 2025-06-02 21:09 ` Cavitt, Jonathan
2025-06-02 21:31 ` Lucas De Marchi
1 sibling, 0 replies; 16+ messages in thread
From: Cavitt, Jonathan @ 2025-06-02 21:09 UTC (permalink / raw)
To: Ceraolo Spurio, Daniele, Wajdeczko, Michal, K V P, Satyanarayana,
igt-dev@lists.freedesktop.org, De Marchi, Lucas
Cc: Dugast, Francois, Harrison, John C, 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
> >>>>
> >>
>
>
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH i-g-t] tests/intel/xe_fault_injection: Ignore all errors while injecting fault
2025-06-02 20:31 ` Daniele Ceraolo Spurio
2025-06-02 21:09 ` Cavitt, Jonathan
@ 2025-06-02 21:31 ` Lucas De Marchi
1 sibling, 0 replies; 16+ messages in thread
From: Lucas De Marchi @ 2025-06-02 21:31 UTC (permalink / raw)
To: Daniele Ceraolo Spurio
Cc: Cavitt, Jonathan, Wajdeczko, Michal, K V P, Satyanarayana,
igt-dev@lists.freedesktop.org, Dugast, Francois, Harrison, John C
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
>>>>>
>>>
>
^ permalink raw reply [flat|nested] 16+ messages in thread
* ✗ Fi.CI.BUILD: failure for tests/intel/xe_fault_injection: Ignore all errors while injecting fault
2025-05-29 13:31 [PATCH i-g-t] tests/intel/xe_fault_injection: Ignore all errors while injecting fault Satyanarayana K V P
2025-05-29 14:22 ` Cavitt, Jonathan
2025-05-29 16:23 ` Daniele Ceraolo Spurio
@ 2025-05-29 18:40 ` Patchwork
2025-05-29 20:14 ` [PATCH i-g-t] " Michal Wajdeczko
2025-05-30 17:38 ` Kamil Konieczny
4 siblings, 0 replies; 16+ messages in thread
From: Patchwork @ 2025-05-29 18:40 UTC (permalink / raw)
To: Satyanarayana K V P; +Cc: igt-dev
== 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".
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH i-g-t] tests/intel/xe_fault_injection: Ignore all errors while injecting fault
2025-05-29 13:31 [PATCH i-g-t] tests/intel/xe_fault_injection: Ignore all errors while injecting fault Satyanarayana K V P
` (2 preceding siblings ...)
2025-05-29 18:40 ` ✗ Fi.CI.BUILD: failure for " Patchwork
@ 2025-05-29 20:14 ` Michal Wajdeczko
2025-05-29 21:48 ` Cavitt, Jonathan
2025-05-30 17:38 ` Kamil Konieczny
4 siblings, 1 reply; 16+ messages in thread
From: Michal Wajdeczko @ 2025-05-29 20:14 UTC (permalink / raw)
To: Satyanarayana K V P, igt-dev, Daniele Ceraolo Spurio
Cc: Francois Dugast, Jonathan Cavitt, John Harrison
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)
^ permalink raw reply [flat|nested] 16+ messages in thread* RE: [PATCH i-g-t] tests/intel/xe_fault_injection: Ignore all errors while injecting fault
2025-05-29 20:14 ` [PATCH i-g-t] " Michal Wajdeczko
@ 2025-05-29 21:48 ` Cavitt, Jonathan
2025-05-30 17:39 ` Kamil Konieczny
2025-06-02 13:00 ` Michal Wajdeczko
0 siblings, 2 replies; 16+ messages in thread
From: Cavitt, Jonathan @ 2025-05-29 21:48 UTC (permalink / raw)
To: Wajdeczko, Michal, K V P, Satyanarayana,
igt-dev@lists.freedesktop.org, Ceraolo Spurio, Daniele
Cc: Dugast, Francois, Harrison, John C, 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
>
>
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [PATCH i-g-t] tests/intel/xe_fault_injection: Ignore all errors while injecting fault
2025-05-29 21:48 ` Cavitt, Jonathan
@ 2025-05-30 17:39 ` Kamil Konieczny
2025-06-02 13:00 ` Michal Wajdeczko
1 sibling, 0 replies; 16+ messages in thread
From: Kamil Konieczny @ 2025-05-30 17:39 UTC (permalink / raw)
To: Cavitt, Jonathan
Cc: Rodrigo Vivi, Wajdeczko, Michal, K V P, Satyanarayana,
igt-dev@lists.freedesktop.org, Ceraolo Spurio, Daniele,
Dugast, Francois, Harrison, John C
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
>
> >
> >
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [PATCH i-g-t] tests/intel/xe_fault_injection: Ignore all errors while injecting fault
2025-05-29 21:48 ` Cavitt, Jonathan
2025-05-30 17:39 ` Kamil Konieczny
@ 2025-06-02 13:00 ` Michal Wajdeczko
2025-06-02 15:17 ` Cavitt, Jonathan
1 sibling, 1 reply; 16+ messages in thread
From: Michal Wajdeczko @ 2025-06-02 13:00 UTC (permalink / raw)
To: Cavitt, Jonathan, K V P, Satyanarayana,
igt-dev@lists.freedesktop.org, Ceraolo Spurio, Daniele,
Rodrigo Vivi
Cc: Dugast, Francois, Harrison, John C
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
>
>>
>>
^ permalink raw reply [flat|nested] 16+ messages in thread* RE: [PATCH i-g-t] tests/intel/xe_fault_injection: Ignore all errors while injecting fault
2025-06-02 13:00 ` Michal Wajdeczko
@ 2025-06-02 15:17 ` Cavitt, Jonathan
0 siblings, 0 replies; 16+ messages in thread
From: Cavitt, Jonathan @ 2025-06-02 15:17 UTC (permalink / raw)
To: Wajdeczko, Michal, K V P, Satyanarayana,
igt-dev@lists.freedesktop.org, Ceraolo Spurio, Daniele,
Vivi, Rodrigo
Cc: Dugast, Francois, Harrison, John C
-----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
> >
> >>
> >>
>
>
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH i-g-t] tests/intel/xe_fault_injection: Ignore all errors while injecting fault
2025-05-29 13:31 [PATCH i-g-t] tests/intel/xe_fault_injection: Ignore all errors while injecting fault Satyanarayana K V P
` (3 preceding siblings ...)
2025-05-29 20:14 ` [PATCH i-g-t] " Michal Wajdeczko
@ 2025-05-30 17:38 ` Kamil Konieczny
4 siblings, 0 replies; 16+ messages in thread
From: Kamil Konieczny @ 2025-05-30 17:38 UTC (permalink / raw)
To: Satyanarayana K V P
Cc: Rodrigo Vivi, igt-dev, Michal Wajdeczko, Francois Dugast,
Jonathan Cavitt, John Harrison
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
>
^ permalink raw reply [flat|nested] 16+ messages in thread