From: Peter Senna Tschudin <peter.senna@linux.intel.com>
To: Lucas De Marchi <lucas.demarchi@intel.com>,
igt-dev@lists.freedesktop.org
Cc: "Francois Dugast" <francois.dugast@intel.com>,
"Zbigniew Kempczyński" <zbigniew.kempczynski@intel.com>
Subject: Re: [PATCH i-g-t 0/4] Device scan fixes
Date: Wed, 18 Dec 2024 09:16:48 +0100 [thread overview]
Message-ID: <4f4cb4c0-317c-4b5a-a37a-c30dd1be57c9@linux.intel.com> (raw)
In-Reply-To: <20241218051324.2696557-1-lucas.demarchi@intel.com>
On 18.12.2024 06:13, Lucas De Marchi wrote:
> This started with the goal of fixing xe_wedged (besides the fix to the
> kernel that is in flight), however the issue of device "disappearing
> from bus" looks similar to several other issues we occasionally have -
> it may be the same issue. Try to fix it by forcing scans.
Is the hypothesis that while an IGT test is running something may
break the association between GPU and device node? I am asking because
the drm device is always closed after a test ends.
I tested this by printing the value of _opened_fds_count from
lib/drmtest.c before each test, and the value is always 0.
_opened_fds_count being zero means that the cache is empty, right? So
if the cache is empty before each test starts, under which conditions
can the potential problem manifest?
next prev parent reply other threads:[~2024-12-18 8:16 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-18 5:13 [PATCH i-g-t 0/4] Device scan fixes Lucas De Marchi
2024-12-18 5:13 ` [PATCH i-g-t 1/4] lib/drmtest: Fix drm_close_driver() Lucas De Marchi
2024-12-18 5:13 ` [PATCH i-g-t 2/4] lib/igt_sysfs: Fix close when rebinding Lucas De Marchi
2024-12-18 5:13 ` [PATCH i-g-t 3/4] lib/igt_sysfs: Move close to be common to all actions Lucas De Marchi
2024-12-18 5:13 ` [PATCH i-g-t 4/4] lib/igt_device_scan: Fix scan vs bind/unbind/reload Lucas De Marchi
2024-12-18 6:07 ` Peter Senna Tschudin
2024-12-18 6:17 ` Zbigniew Kempczyński
2024-12-20 19:10 ` Lucas De Marchi
2024-12-18 6:34 ` Zbigniew Kempczyński
2024-12-19 16:35 ` Lucas De Marchi
2024-12-20 6:59 ` Zbigniew Kempczyński
2024-12-20 18:52 ` Lucas De Marchi
2024-12-18 8:20 ` Kamil Konieczny
2024-12-18 8:16 ` Peter Senna Tschudin [this message]
2024-12-18 22:04 ` [PATCH i-g-t 0/4] Device scan fixes Lucas De Marchi
2024-12-19 8:44 ` Peter Senna Tschudin
2024-12-18 20:55 ` ✓ i915.CI.BAT: success for " Patchwork
2024-12-18 23:00 ` ✓ Xe.CI.BAT: " Patchwork
2024-12-19 10:18 ` ✗ i915.CI.Full: failure " Patchwork
2024-12-19 14:13 ` ✗ Xe.CI.Full: " 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=4f4cb4c0-317c-4b5a-a37a-c30dd1be57c9@linux.intel.com \
--to=peter.senna@linux.intel.com \
--cc=francois.dugast@intel.com \
--cc=igt-dev@lists.freedesktop.org \
--cc=lucas.demarchi@intel.com \
--cc=zbigniew.kempczynski@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