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

Michal Wajdeczko michal.wajdeczko at intel.com
Mon Jun 2 13:00:42 UTC 2025



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

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



More information about the igt-dev mailing list