Re: [PATCH v1 3/4] drm/xe/guc/ct: Queue G2H worker before flushing it in timeout paths

[Matthew Brost <matthew.brost@intel.com>]

On Thu, Jul 23, 2026 at 07:31:10PM -0300, Tales A. Mendonça wrote:
> > What about the H2G CT?
> 
> Hi Matt,
> 
> Thanks for the series and for the H2G question — I extended my
> instrumentation to sample the H2G CTB descriptor as well, and I now
> have results from two ARL machines running your series 170939.
> 
> Setup:
> - Machine A: ARL-H (PCI 7d51, Core Ultra 5 225H)
> - Machine B: ARL-P (PCI 7dd1, Core Ultra 7 255H)
> - Both: GuC firmware 70.53.0, kernel 7.1.3 with your two patches
> backported, plus debug-only instrumentation that samples both CTB
> descriptors and the GT C-state at TDR time and logs late acks. My
> earlier G2H-flush patch (3/4 of my series) is NOT applied, so your CPU
> flush WA is the only recovery path in place, with the stock
> invalidation timeout.
> 
> Results, 7 timeout events so far (6 on machine A, 1 on machine B),
> identical signature on every single one:
> 
>   TLB invalidation timeout gtidle: seqno=89335, gt_c_state request=C0
>     timeout=C6, c6_residency request-to-timeout=2278ms, waited=2279ms
>   TLB invalidation timeout g2h: seqno=89335, ctb pending=0 dw,
>     head=23932, tail=23932, outstanding=1
>   TLB invalidation timeout h2g: seqno=89335, ctb pending=0 dw,
>     head=792, tail=792
>   TLB invalidation late ack: seqno=89335 recv=89335,
>     request-to-ack=2325ms, timeout-to-ack=45ms
> 
> To answer your question directly: the H2G CTB is fully drained at TDR
> time — head == tail as read from the shared descriptor, i.e. the GuC's
> own view of its consumption progress. So the invalidation request is
> not sitting unconsumed in the H2G ring. Combined with the empty G2H
> ring (with one outstanding G2H credit) this means the GuC consumed the
> request but did not send the ack until 2-45ms after the TDR fired,
> roughly 2.3s after the request was posted.
> 
> Also worth noting: your "CPU flush WA resolved %u pending TLB inval
> fence(s)" warning has not fired once across many hours on either
> machine, while 7 timeouts went through the recovery path. So at least
> on ARL the LNL flush WA does not appear to be the mechanism — there is
> no G2H sitting unprocessed on the host side; the ack genuinely arrives
> late from the firmware.
> 
> Everything points at a GuC 70.53.0 stall: request consumed, ack

Yes, this looks like something is going on in the GuC.

> delayed by seconds, firmware "wakes up" right around the TDR. If it
> would help I can file a gitlab issue with the full logs from both
> machines, and I am happy to keep collecting events (the two machines
> produce a steady trickle).

I'd file a gitlab.

> 
> I would also like to give xe_devcoredump_gt() a try as a separate
> series, as you suggested, if no one else is already on it.
> 

If you could wire up `xe_devcoredump_gt` and attach the devcoredump so
we can inspect the GuC log, it would probably be worth us taking a quick
look.
 
We do support ARL on i915, and the firmware is the same. In general, the
GuC firmware operates similarly across most platforms, so it's quite
possible that whatever is happening here could also be an issue on other
platforms.

Matt

> Thanks,
> Tales