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
