From 4094a7ea7e8ed92f323e856fcac3717df0f4b401 Mon Sep 17 00:00:00 2001 From: Arthur Hanson Rasmusson Date: Fri, 23 Oct 2026 15:25:51 -0400 Subject: vgsp-sema r558: the opdef hold path honors the absolute per-launch bound r557 STALL-DUMP evidence (victory_matmul): "no GPFIFO entry consumed for 20s" repeated while opdef=3880/16/64 and held=155 climbed - the pump froze on one held entry whose operand never resolved, re-holding it every pass. The opdef hold was the only pump hold path without the absolute per-launch-VA bound (svc_gr_hold_bound_expired, the r509 one-shot used by every GR hold path); it could therefore extend indefinitely through fresh slot allocations even though each individual slot window is 3 s. Consult the same absolute bound before holding: once it fires the entry flushes its withheld releases and is consumed, so no operand-pending entry can freeze the pump's entry loop. --- kernel/gsp_sema_service.c | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) (limited to 'kernel/gsp_sema_service.c') diff --git a/kernel/gsp_sema_service.c b/kernel/gsp_sema_service.c index a3366ba..d3a7e31 100644 --- a/kernel/gsp_sema_service.c +++ b/kernel/gsp_sema_service.c @@ -22649,7 +22649,27 @@ static void svc_pump_channels(struct nv_vgpu_device *vgpu) * data), so the hold and the * deferral move together. */ + /* + * r558: the opdef hold is the one + * pump hold path without the + * absolute per-launch bound. r557 + * STALL-DUMP evidence: the pump + * consumed NOTHING for 20+ s while + * held/opdef counters climbed + * (opdef=3880/16/64, held=155) - + * a held entry whose operand never + * resolves was re-held every pass + * and the whole pump froze on it. + * Consult the same absolute + * per-launch-VA bound the GR hold + * paths use (svc_gr_hold_bound_ + * expired, one-shot r509): once it + * fires the entry flushes and is + * consumed instead of held again. + */ if (svc.op_tr_pending && + !svc_gr_hold_bound_expired(ch, + svc_gr_launch_va(ch)) && svc_opdef_hold(vgpu, ch, (u32)idx, va)) { -- cgit v1.2.3