> You've been approved in our CI for future revs. Thanks!
> Also I came across this issue on i915 for MTL [1] which appears to > indicate the same issue (ARL and MTL are very close and share the same GuC > firmware), the suggestion is to disable rc6. Unfortunately Xe > doesn't have a knob for this, but per [1] you can turn off rc6 > in the BIOS. Maybe worth trying. Good find - that does look like the same ~2.3s signature, and it being visible on i915/MTL too is an important data point (Daniele asked exactly that in the other subthread). On the rc6 angle: I ran an A/B experiment earlier that should be equivalent to disabling rc6 at the GT level - holding forcewake across the whole GT for hours (C6 residency pinned at 0ms for the entire window, verified) - and still hit 9 timeouts in a row, with the same ~2.3s request-to-ack. So at least keeping the GT out of RC6 does not avoid the stall here. If the BIOS suggestion covers more than GT RC6 (e.g. package C-states), that would be a different experiment - my consumer ASUS BIOS does not expose an rc6 knob, but I can look for C-state options if you think it is worth isolating. Next on my side: switching to the GuC 70.72.1 build Daniele posted and reporting back, plus GuC logs from severe stalls are now attached to the gitlab issue. Thanks, Tales Em qua., 5 de ago. de 2026 às 17:25, Matthew Brost <[email protected]> escreveu: > > On Tue, Aug 04, 2026 at 02:29:27PM -0700, Matthew Brost wrote: > > On Tue, Aug 04, 2026 at 01:34:19PM -0300, Tales A. Mendonça wrote: > > > Patchwork reports my address is not on the CI allowlist, so CI was not > > > triggered for this series: > > > > > > Series author address '[email protected]' is not on the allowlist, > > > which prevents CI from being automatically triggered. > > > > > > Could one of the project owners click 'retest' on the series (and/or > > > add me to the allowlist)? Series URL: > > > > > > https://patchwork.freedesktop.org/series/171539/ > > > > > > > We'd have to resend this ourselves. I can do this, but I've requested > > for you to be on our allow list as well. I'll ping here once that goes > > through. > > > > You are approved on our CI for future patches. > > Also I came across this issue in the i915 for MTL [1] which seems to > indicate the same issue (ARL and MTL are very close and share same GuC > firmware), the suggestion there is turn off rc6. Unfortunately Xe > doesn't have a knob to do this but according to [1] you can turn off rc6 > in the BIOS. Might be worth a try. > > Matt > > [1] https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/14469 > > > Matt > > > > > Thanks! > > > Tales > > > > > > > > > Em seg., 3 de ago. de 2026 às 23:14, Tales A. Mendonça > > > <[email protected]> escreveu: > > > > > > > > Hi, > > > > > > > > This series is a follow-up to the TLB invalidation ack stall I have > > > > been debugging on ARL, tracked in: > > > > > > > > https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/8678 > > > > > > > > Summary of the issue: with GuC 70.53.0 on ARL (reproduced on 7d51 and > > > > 7dd1 machines here, plus an independent Arc Pro 130T report on the > > > > issue above), TLB invalidation acks intermittently stall for ~2.3s. > > > > The H2G request is consumed from the CTB immediately and the G2H CTB > > > > is empty the whole time - the firmware simply does not send the ack > > > > until much later. The fence timeout fires at 2.25s and the ack lands > > > > tens of ms after it. Userspace blocked on the invalidation (compositor > > > > buffer unmaps etc.) hitches for the full window. > > > > > > > > Patch 1 adds xe_devcoredump_gt() so this kind of hang - which has no > > > > exec queue or job to blame - leaves a devcoredump with the GuC log and > > > > CT state behind (Matt suggested capturing devcoredumps when we > > > > discussed the issue; devcoredumps from both machines are attached to > > > > the issue above). > > > > > > > > Patch 2 logs when the ack for a timed out invalidation finally > > > > arrives. This is what established that the acks are late rather than > > > > lost. > > > > > > > > Patch 3 is the RFC part: a delayed work that pokes the GuC (status > > > > register read, CT flush, doorbell ring) every 250ms while an ack is > > > > overdue. On my machines this converts the guaranteed 2.3s stall into a > > > > sub-500ms hiccup for the majority of occurrences; a minority of severe > > > > episodes ignore 8-9 consecutive doorbells, which points at the GuC > > > > firmware being internally blocked for the whole window. Full data on > > > > the issue. I am happy to rework the approach (different delay, > > > > tying it to the G2H handler, dropping the status read, etc.) - mainly > > > > I would like the firmware side investigated, since no host-side poke > > > > can fix the severe cases. > > > > > > > > Based on drm-tip. Tested for several days on both ARL machines under > > > > desktop and VM-heavy workloads. > > > > > > > > Thanks, > > > > Tales > > > > > > > > Tales A. Mendonça (3): > > > > drm/xe: Capture devcoredump on TLB invalidation timeout > > > > drm/xe: Log when a timed out TLB invalidation ack finally arrives > > > > drm/xe: Kick GuC while TLB invalidation acks are overdue > > > > > > > > drivers/gpu/drm/xe/xe_devcoredump.c | 68 ++++++++++++ > > > > drivers/gpu/drm/xe/xe_devcoredump.h | 6 ++ > > > > drivers/gpu/drm/xe/xe_tlb_inval.c | 131 +++++++++++++++++++++++- > > > > drivers/gpu/drm/xe/xe_tlb_inval_types.h | 42 ++++++++ > > > > 4 files changed, 243 insertions(+), 4 deletions(-) > > > > > > > > -- > > > > 2.55.0 > > > > > > > > > > > > > -- > > > Com os cumprimentos, > > > > > > Tales A. Mendonça > > > talesam.org > > > communitybig.org -- Com os cumprimentos, Tales A. Mendonça talesam.org communitybig.org
