On 02/11/2022 12:12, Jani Nikula wrote:
On Tue, 01 Nov 2022, John.C.Harrison@xxxxxxxxx wrote:
From: John Harrison <John.C.Harrison@xxxxxxxxx>
At the end of each test, IGT does a drop caches call via sysfs with
sysfs?
special flags set. One of the possible paths waits for idle with an
infinite timeout. That causes problems for debugging issues when CI
catches a "can't go idle" test failure. Best case, the CI system times
out (after 90s), attempts a bunch of state dump actions and then
reboots the system to recover it. Worst case, the CI system can't do
anything at all and then times out (after 1000s) and simply reboots.
Sometimes a serial port log of dmesg might be available, sometimes not.
So rather than making life hard for ourselves, change the timeout to
be 10s rather than infinite. Also, trigger the standard
wedge/reset/recover sequence so that testing can continue with a
working system (if possible).
Signed-off-by: John Harrison <John.C.Harrison@xxxxxxxxx>
---
drivers/gpu/drm/i915/i915_debugfs.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c
index ae987e92251dd..9d916fbbfc27c 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -641,6 +641,9 @@ DEFINE_SIMPLE_ATTRIBUTE(i915_perf_noa_delay_fops,
DROP_RESET_ACTIVE | \
DROP_RESET_SEQNO | \
DROP_RCU)
+
+#define DROP_IDLE_TIMEOUT (HZ * 10)
I915_IDLE_ENGINES_TIMEOUT is defined in i915_drv.h. It's also only used
here.
So move here, dropping i915 prefix, next to the newly proposed one?
I915_GEM_IDLE_TIMEOUT is defined in i915_gem.h. It's only used in
gt/intel_gt.c.
Move there and rename to GT_IDLE_TIMEOUT?
I915_GT_SUSPEND_IDLE_TIMEOUT is defined and used only in intel_gt_pm.c.
No action needed, maybe drop i915 prefix if wanted.
I915_IDLE_ENGINES_TIMEOUT is in ms, the rest are in jiffies.
Add _MS suffix if wanted.
My head spins.
I follow and raise that the newly proposed DROP_IDLE_TIMEOUT applies to
DROP_ACTIVE and not only DROP_IDLE.
Things get refactored, code moves around, bits get left behind, who
knows. No reason to get too worked up. :) As long as people are taking a
wider view when touching the code base, and are not afraid to send
cleanups, things should be good.
For the actual functional change at hand - it would be nice if code
paths in question could handle SIGINT and then we could punt the
decision on how long someone wants to wait purely to userspace. But it's
probably hard and it's only debugfs so whatever.
Whether or not 10s is enough CI will hopefully tell us. I'd probably err
on the side of safety and make it longer, but at most half from the test
runner timeout.
I am not convinced that wedging is correct though. Conceptually could be
just that the timeout is too short. What does wedging really give us, on
top of limiting the wait, when latter AFAIU is the key factor which
would prevent the need to reboot the machine?
Regards,
Tvrtko
