vgsp-sema r633: park a held GR launch's push-level release records and deliver them on the eventual forward (the r632 mail hang), gate synthetic shadow pages on an anchored span with per-episode budgets (the r632 junk-candidate flood), and name the release0 redirect cause

The r632 first boot's mail client spun forever in cudaDeviceSynchronize
after its vadd launch: the push-level tracking release (0x20480fff0
pay=112) never landed while the client's word stayed at 111, even though
the launch itself completed (GUEST GR LAUNCH OK) and its QMD release was
software-applied.  Root cause: the release records (svc_fwd_rel[]) are
per-decode state (reset at the top of svc_decode_stream), and the two GR
hold paths (busy-defer hold, m150 data-stalled hold) break out of the
pump entry loop BEFORE the release block (hold-engage / inline apply)
runs - so a held launch's records are dropped at the pass boundary.  The
eventual forward (queued from the capture ring at the defer cap, without
a re-decode of the entry) then engaged the release hold with whatever
records that pass happened to carry (often none, or another entry's).
Live evidence: read_proc_va on the spinning client - 0x20480fff0 = 111
(payload 112 never applied), 0x204827f74 = 6 (QMD release delivered);
host log - no sema-sw line for 0x20480fff0 val=0x70 anywhere.

Fix (parked releases, keyed by vgpu/channel/push VA): both hold paths
park the pass's records (svc_grpark_put) before their break; svc_gr_request
restores the queued push's parked set into svc_fwd_rel[] at the consume
point so the pump's hold-engage holds exactly those records; the two
fail-closed REFUSED paths deliver the parked set inline; the session
flush clears the table.  Bounded log line "GR parked releases restored"
(32/boot).  Proven live: r633 first boot restored push=0x20043c1c8
n=1 va0=0x20480fff0 pay0=100; r633 mail now completes (VADD bad=0
checksum=12204516.000000, STATUS OK) on two consecutive fresh boots.

Also r633: the r632 synthetic shadow caps were per-FILL-CALL and the fill
re-runs on every retry pass, so one probe=none junk argument candidate
could mint another 1024 synthetic pages per pass - the 8192-page shadow
table filled within seconds of the r632 first launch (va-shadow
8192/8192, all synthetic, from the two 16 MB guessed spans of candidates
no resolver ever answered), which then killed the lane for every later
real page ("shadow table full ... write dropped").  Two changes:
  - ANCHOR GATE: a synthetic page is created only when the candidate's
    span already has >= 1 page answered by ipin/resolve/ledger.  Existing
    H2D shadow content still serves unconditionally (the red-draw chain),
    and a real buffer's unresolved tail stays anchored by its resolved
    head.  A candidate whose every page is answerless takes the
    historical drop path - its guessed span is not a buffer;
  - PER-EPISODE BUDGETS: the per-candidate (1024) and per-launch (4096)
    caps now persist per (push VA, span base) across the episode's
    passes, not per call.
Measured r633: shadow table peak 2048/8192 (vs 8192/8192 full), 32
synthetic pages for the mail launch (vs 4041 junk-inflated n_data), the
lane stays available for content serves.

Diagnostics (bounded, one boot of evidence): "vgsp-work: gr-rel0 ..."
names the release0 resolution chain (rel_pa/ap/hpa/word/pay/unobs) and
"vgsp-gr: qmd-rel redirect: ..." names the backend redirect cause.  The
first live reading answers the release-target question: rel_hpa resolves
(0x2fc495000), map_ret=0, unobs=0 - the redirect is the deliberate
gsp_phys_rmcall_gr_rel_mod=1 default (m64 forced module-semaphore
release), not a resolver failure.  The r632 hang was the push-level
release loss, fixed above.

Build clean (kernel + r65535 warnings only).

0 files changed, 0 insertions, 0 deletions