> 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
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 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.
Thanks,
Tales
