vgsp-sema r613: a wait-gate give-up is deferred while a GR forward is owed - the release sits behind our own launch deferral

The r34x acquire wait gate gives up (fail-open, ops run) after
gsp_sema_wait_hold_ms with no satisfiable value, on the premise that the
value cannot be installed by firmware alone. That premise is false while we
are holding the launch that authors the release: the r612 streams2 capture
gave up the D2H readback's acquire (ch=0x5c00005f va=0x20480ffe0 op=3 pay=4
cur=2 waited_ms=10333) while the vadd launches that release that semaphore
sat deferred by the CE watermark for the full 15 s cap; the readback then
ran BEFORE the kernels and the client read zeros (STREAMS bad=65534 even
with the launches forwarded and GUEST GR LAUNCH OK).

While any captured candidate is still unoffered (svc_gr_forward_pending),
extend the episode up to wait-hold + SVC_GR_DEFER_CAP_MS + 5 s margin and
log 'extend' instead of giving up. Every client-side timeout is >= 60 s, so
a <= 24 s episode cannot strand the client; when no forward is pending the
give-up is unchanged.

0 files changed, 0 insertions, 0 deletions