From: Francois Dugast <francois.dugast@intel.com>
To: Satyanarayana K V P <satyanarayana.k.v.p@intel.com>
Cc: igt-dev@lists.freedesktop.org,
"Michał Wajdeczko" <michal.wajdeczko@intel.com>
Subject: Re: [PATCH i-g-t v2 5/5] tests/intel/xe_fault_injection: Do not assert if the captured error is not same as injected error.
Date: Wed, 5 Mar 2025 12:53:15 +0100 [thread overview]
Message-ID: <Z8g7K-Mvf5yGptuK@fdugast-desk> (raw)
In-Reply-To: <20250219073445.31423-6-satyanarayana.k.v.p@intel.com>
On Wed, Feb 19, 2025 at 01:04:45PM +0530, Satyanarayana K V P wrote:
> In the current implementation, test asserts if the captured error is not same as
> injected error. It is a possible that the error received is translated to other
> error which can be returned to application.
>
> Try to unbind the device at the end of inject_fault_probe() as this can be
> executed in a loop if IGT_FAULT_INJECT_ITERATION environment variable is set.
>
> Signed-off-by: Satyanarayana K V P <satyanarayana.k.v.p@intel.com>
> Cc: Michał Wajdeczko <michal.wajdeczko@intel.com>
> Cc: Francois Dugast <francois.dugast@intel.com>
> ---
> tests/intel/xe_fault_injection.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tests/intel/xe_fault_injection.c b/tests/intel/xe_fault_injection.c
> index cf0337733..82e338965 100644
> --- a/tests/intel/xe_fault_injection.c
> +++ b/tests/intel/xe_fault_injection.c
> @@ -227,8 +227,8 @@ inject_fault_probe(int fd, char pci_slot[], const char function_name[])
> injection_list_do(INJECTION_LIST_ADD, function_name);
> set_retval(function_name, INJECT_ERRNO);
> xe_sysfs_driver_do(fd, pci_slot, XE_SYSFS_DRIVER_TRY_BIND);
> - igt_assert_eq(-errno, INJECT_ERRNO);
> injection_list_do(INJECTION_LIST_REMOVE, function_name);
> + xe_sysfs_driver_do(fd, pci_slot, XE_SYSFS_DRIVER_TRY_UNBIND);
Those should be 2 separate patches.
1. Try driver unbind after fault injection during probe
2. Accept returned error different than injected one
I am fine with 1. as it is, just the one line.
However removing the assert in 2. is not acceptable. This assert *IS*
the real test performed for existing fault injection tests. If we
remove it then we will not be able to detect when probing does not
behave as expected in case of failure.
We need a more flexible solution to your problem, such as adding one
parameter to inject_fault_probe() with the expected returned error
code.
Francois
> }
>
> /**
> --
> 2.35.3
>
next prev parent reply other threads:[~2025-03-05 11:53 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-19 7:34 [PATCH i-g-t v2 0/5] tests/intel/xe_fault_injection: Inject errors during xe_guc_ct_send_recv() xe_guc_mmio_send_recv() Satyanarayana K V P
2025-02-19 7:34 ` [PATCH i-g-t v2 1/5] lib/igt_sysfs: Add support for device unbinding Satyanarayana K V P
2025-02-19 7:34 ` [PATCH i-g-t v2 2/5] tests/intel/xe_fault_injection: Make setup_injection_fault() programmable Satyanarayana K V P
2025-02-28 10:33 ` Francois Dugast
2025-02-19 7:34 ` [PATCH i-g-t v2 3/5] tests/intel/xe_fault_injection: Add helper functions to inject fault with specific budget parameter Satyanarayana K V P
2025-03-05 10:28 ` Francois Dugast
2025-03-06 9:56 ` K V P, Satyanarayana
2025-02-19 7:34 ` [PATCH i-g-t v2 4/5] tests/intel/xe_fault_injection: Inject errors during xe_guc_ct_send_recv & xe_guc_mmio_send_recv Satyanarayana K V P
2025-03-05 10:50 ` Francois Dugast
2025-03-05 11:07 ` K V P, Satyanarayana
2025-02-19 7:34 ` [PATCH i-g-t v2 5/5] tests/intel/xe_fault_injection: Do not assert if the captured error is not same as injected error Satyanarayana K V P
2025-03-05 11:53 ` Francois Dugast [this message]
2025-03-06 9:57 ` K V P, Satyanarayana
2025-03-21 10:37 ` Bernatowicz, Marcin
2025-02-19 8:26 ` ✓ Xe.CI.BAT: success for tests/intel/xe_fault_injection: Inject errors during xe_guc_ct_send_recv() xe_guc_mmio_send_recv() (rev2) Patchwork
2025-02-19 8:40 ` ✓ i915.CI.BAT: " Patchwork
2025-02-19 10:26 ` ✓ i915.CI.Full: " Patchwork
2025-02-20 5:01 ` ✗ Xe.CI.Full: failure " Patchwork
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Z8g7K-Mvf5yGptuK@fdugast-desk \
--to=francois.dugast@intel.com \
--cc=igt-dev@lists.freedesktop.org \
--cc=michal.wajdeczko@intel.com \
--cc=satyanarayana.k.v.p@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox