From: Jani Nikula <jani.nikula@linux.intel.com>
To: Matthew Brost <matthew.brost@intel.com>,
Lucas De Marchi <lucas.demarchi@intel.com>
Cc: intel-xe@lists.freedesktop.org
Subject: Re: [RFC PATCH 1/1] drm/xe: Add driver load error injection
Date: Tue, 13 Aug 2024 13:59:13 +0300 [thread overview]
Message-ID: <87ttfozo1q.fsf@intel.com> (raw)
In-Reply-To: <ZrduH7WZvUGDxUSg@DUT025-TGLU.fm.intel.com>
On Sat, 10 Aug 2024, Matthew Brost <matthew.brost@intel.com> wrote:
> On Sat, Aug 10, 2024 at 12:16:32AM -0500, Lucas De Marchi wrote:
>> On Fri, Aug 09, 2024 at 03:44:24PM GMT, Matthew Brost wrote:
>> > Port over i915 driver load error injection.
>> >
>>
>> I don't like much the manual approach, but it's better to get the driver
>> not exploding. Then we can think of replacing this. Some comments below
>
> Yep. I chatted with Rodrigo about this and we agreed their isn't a great
> way with the existing kernel error injection to easily get coverage like
> this plus a very simple test case [1]. Agree longterm we should not
> invent our own things and come up with either a kernel or drm level
> solution.
>
> In the short term, yes this better than our driver exploding. View this
> as a force probe blocker, so we need to get our driver fixed in a matter
> of weeks and this seems like the only viable path for now.
>
> [1] for i in {1..N}; do echo "Run $i"; modprobe xe inject_driver_load_error=$i; rmmod xe; done
*sad trombone*
It just pains me that we keep copy-pasting stuff from i915, especially
when it's the hacky less than stellar parts. Like this one.
Fixing this needs to go to some tracker somewhere, and get it assigned,
otherwise later means never.
BR,
Jani.
--
Jani Nikula, Intel
next prev parent reply other threads:[~2024-08-13 10:59 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-09 22:44 [RFC PATCH 0/1] Add driver load error injection Matthew Brost
2024-08-09 22:44 ` [RFC PATCH 1/1] drm/xe: " Matthew Brost
2024-08-10 5:16 ` Lucas De Marchi
2024-08-10 13:41 ` Matthew Brost
2024-08-10 16:01 ` Lucas De Marchi
2024-08-11 22:09 ` Matthew Brost
2024-08-13 10:59 ` Jani Nikula [this message]
2024-08-10 0:00 ` ✓ CI.Patch_applied: success for " Patchwork
2024-08-10 0:00 ` ✗ CI.checkpatch: warning " Patchwork
2024-08-10 0:01 ` ✗ CI.KUnit: failure " Patchwork
2024-08-13 10:47 ` [RFC PATCH 0/1] " Jani Nikula
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=87ttfozo1q.fsf@intel.com \
--to=jani.nikula@linux.intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=lucas.demarchi@intel.com \
--cc=matthew.brost@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