| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
| |
r639 streams2 transcript has the readback's acquire giving up at waited_ms=28378 while the launch whose release it waits for only forwarded ~9 s later (watermark defer + arg-partial defer + backend poll chained past the 25 s bound), so the readback ran out of order and the client read zeros (bad=65534); 45 s keeps >15 s of headroom under the clients' >= 60 s timeouts and only engages while a GR forward is unoffered (green boots never reach it)
|
| |
|
|
| |
path - egl_retry (explicit EGL make-current retry probe: the glsi engine-init returns busy once and eglcore never retries; prints the per-try EGL error), xshm_pub (X11/XShm screen capture into the kvmfr ivshmem BAR in the frame_producer layout so a GL/Vulkan-rendered guest frame reaches the host), xorg-vgpu.conf (headless nvidia Xorg server layout for the emulated vGPU)
|
| |
|
|
| |
whose unconsumed head entry is wait-gate held is a consumer-side wait, not a producer backlog; the watermark skips it while the candidate's operands are fully resolved and no decoded device write is pending, so the deferred launch forwards and its release installs (the r612/r636 streams chain: readback acquire op=3 pay=N sits behind the very launch whose release it wants, the two defer each other for the full 15 s cap and the copy runs ~20 s late); module param sema_mutual_skip (default 1, 0 = r636 behaviour)
|
| |
|
|
| |
operand-resolution gap (content-tracked shadow anchors + launch-level content anchor + bounded cross synth + table guard; the draft's self-feeding mint caught and gated, green-boot table 6144/8192 -> 0 minted), r636 fresh-boot battery best-equal 9 OK / 2 clean FAIL / 1 HANG with streams_events hang->clean CUDA_ERROR and the streams2 red chain measured (H2D dsts replay-denied -> GR forward deferred on the CE stream-order watermark -> degenerate refusal -> SYNTH-FAULT); remaining: streams2 CE-order chain, first-wait crawls, used-boot allocation exhaustion, then 15/15 + soak
|
| |
|
|
| |
per-shadow-page REAL-content tracking (r->content set on every landed write) anchors a client's own H2D-shadowed pages and arms a launch-level content anchor, so an answerless output candidate (contiguous tail of a shadowed input, or a non-contiguous allocation) is served from a bounded synthetic page set (1024/candidate, 4096/launch, 3/4-table guard) instead of failing the launch closed; synthetic pages can never re-anchor (the first draft self-fed on its own minted pages and filled the shared table to the guard - 6144/8192 measured on a green boot - content gating restored 0 minted pages there and the historical green shape); trusted pin/walk/ledger answers keep the r633 anchored budgets and no longer arm the cross mint; fresh r636 boot: best-equal battery 9 OK / 2 clean FAIL / 1 HANG (streams2 bad=65534 - its H2D dsts are replay-denied, the GR forward defers on the CE stream-order watermark, degenerate refusal faults cleanly; streams_events hang->clean CUDA_ERROR via the auto-fault; smiley first-wait crawl)
|
| |
|
|
| |
held GR launches park their push-level release records and the eventual forward delivers them; mail green on two fresh boots), release-target question answered (rel_mod=1 default redirect, resolver works), synthetic shadow caps gated (anchor + per-episode; peak 2048/8192), best-ever battery r633b pass=9 fail=0 hang=1, r631 math red draw green; remaining top blocker = operand-resolution shortfall behind the wrongness class
|
| |
|
|
| |
raise the non-pool device-VA release-write log budget 512 -> 4096/boot - the r633b battery's streams2 spin (userspace, launches completed, QMD releases applied) needs the held records and the release target PA visible; the 512-line budget was exhausted by mid-battery and hid every later application
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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).
|
| |
|
|
| |
(r627), best battery 11/15 zero hangs, r632 shadow-lane operand serving, remaining: release-target resolver + wrongness class
|
| |
|
|
| |
shadow lane (existing H2D content, or a synthetic page for an argument candidate under per-candidate/per-launch caps) instead of dropping them - the submit build hands the shadow page's host address to the bounce machinery, so copy-in stages the client's own bytes and copy-out writes the engine's results into the same page the D2H copies read (red-draw chain: walk=none -> H2D shadow -> fill fail-closes -> degenerate refusal -> SYNTH-FAULT); write guard keeps a shadowed VA's writeback; sema_no_shadow=1 keeps the historical drop path
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
landings - the r623c wrong-write site
The post-loop parity store (r254-era) recorded a large virtual-destination
copy's whole range contiguously (dst + po) AFTER the per-page loop had
already stored each page's true resolved PA (m180/r391). For a scattered
UVM host buffer the contiguity guess overwrote the true entries; the next
copy of the same VA then followed the poisoned ledger (the non-pin DIVERGE
branch keeps the ledger) and wrote client c-data into guest pages the
kernel had since re-used.
r623c evidence chain (saxpy D2H readback of 0x70e64e700000):
sema-ledger: rewrite va=0x70e64e77f000 old=0x12e700000 new=0x115800000
504x sema-ledger: DIVERGE write ... prev=0x1158xxxxx cur=0x12e7xxxxx
guest panic: kchannelGetGfid_IMPL+0x12, garbage 0x44560800445590f0
(IEEE754 floats 854.25/856.125 = client c-data in nvidia channel structs)
Fix: the parity pass skips pages the per-page loop already stored (lookup
guard); it only seeds pages the loop did not reach. True per-page landings
are never overwritten.
|
| |
|
|
| |
(copy-dst + fill fallbacks hold instead); isolates the lane as a variable for the fatal corruption class (nvidia channel structs overwritten with PTE-like patterns -> panic in kchannelGetGfid_IMPL via nvGpuOpsStopChannel; r613c/r616/r623c)
|
| |
|
|
| |
(pause the trace-consuming scanner, read the retained uvtw/uvsv/uvmt tail, walk the tracker + pool page, resume); wraps the manual sequence that unlocked the first-wait evidence
|
| |
|
|
| |
the first-wait class: read a UVM tracker's semaphore object and expected payload, and dump the semaphore-pool page's applied values; together with the host pool-wr/sema-sw logs they compare what the driver waits for against what the host wrote
|
| |
|
|
| |
engine-fault report to the guest's RM queue (debug param; payload mirrors the GSP ABI decode: exceptType/runlistId/chid/errString/prevXid) - the suspected missing recovery half after a synth-fault (post-fault clients stick pre-submission)
|
| |
|
|
| |
/proc/<pid>/mem (the guest-side half of the sem-write divergence comparison; pairs with the r619/r620 sema-sw witness)
|
| |
|
|
| |
SVC_VAS_FLOOR and silently excluded the 0x200000000-0x20fffffff VAS window (the release words it exists for) - use the window base so the r618-style write-target divergence is actually logged
|
| |
|
|
| |
device-VA semaphore writes - the r618 hung math client read 0 at 0x20480fef0 while the host's deferred releases advanced cur 97..105 on its own target; this makes the write-target divergence measurable (bounded 512/boot)
|
| |
|
|
| |
error edge (notifier status=0xffff + channel event, sema_refusal_fault=1 default) - proven live by the r616 grfaultpoke test: the r616b matmul wedge ended with CUDA_ERROR unspecified launch failure instead of spinning forever; rollback = sema_refusal_fault=0
|
| |
|
|
| |
(verdict-in-log completion check; the plain pgrep -x poll falsely hangs on a client that exited after printing its verdict but left an unreaped zombie comm)
|
| |
|
|
| |
(relayed-fault shape: info32=except, info16=engine, status=0xffff, notifier_err latch) and post its channel event, to test whether a synthetic engine-error edge ends a refused launch's cudaDeviceSynchronize spin (the authored sw release lands - measured 0x6 - but the kernel never completes for a never-executed launch)
|
| |
|
|
| |
clients, launch p50 ~650ms, held-chain fix, variance root-caused, GL running, LG frame path proven
|
| |
|
|
| |
unresolved-arg wedge class (sema-shadow-dst entry point, GRFILL-DROP/held/refused chain, untruncated arg-miss walk lists, cand probes, EVPOST drops)
|
| |
|
|
| |
untruncate the arg-miss walk list - the r613b matmul wedge began with an H2D taking the shadow silently (no ledger/pin/walk) and the post-mortem could not see which registered pdb answered what (240B buffer, 3 of 8 entries)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
stalled decoy candidates must not kill a launch whose real operands resolved
r586's fail-closed refused any launch still carrying unresolved argument
pages at the 15 s cap. streams2 as the first client of a fresh boot (r611)
shows the cost: its two launches carry candidates 0x783299000000 and
0x783297000000 that stall in EVERY source from the first fill (no pin, no
walk, no ledger; 'stalled VA' listed, never resolving in the run) while 969
real pages resolve, the r543 arg-defer is pre-empted by the CE watermark
defers, and at the cap both kernels are refused - STREAMS bad=65534 with the
engine never running.
Refuse only a degenerate fill (resolved < dropped - the r584 matmul shape, 2
resolved / 18 dropped, where the engine has no usable window). A
non-degenerate fill at the cap forwards historically and loudly
(fwd_gr_argfw witness): waiting longer cannot resolve a candidate stalled in
every source, and by this point every copy-related guard (dstpend, CE
watermark) has already had its chance and returned above when it fired.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- sibling launch rings caused mutual deferral
r607 made the CE submission watermark watch every other ring. That caught
the copy channel the r568 class needs, but it also caught sibling GR LAUNCH
channels, whose rings legitimately hold the client own future launches:
streams2s two stream channels (h=0x5c00001f/23) each saw the others
published entry as backlog, deferred for the full 15 s cap, and the r586
fail-closed then refused BOTH kernels (r610c streams2 as the first client of
a fresh boot: every launch REFUSED, STREAMS n=32768 bad=65534).
A channel that carries the client stream-ordered memory work is exactly a
channel that has decoded a transfer op; measured across r606/r609/r610c, ops
appear only on the 0x5c000059 copy family and the CE ranks, and the GR
launch channels decode none. Mark it in the op-append block (ever_ops) and
scope the watermark to those channels: the r606 red-draw copy channel stays
in scope, the sibling launch rings no longer defer.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
operand-pending - the held-chain livelock
The fail4 r302 block marks a denied device-destination copy op_tr_pending so
the m163/opdef hold retries it. It fires on EVERY decode pass with
allow=false - including a REPLAY pass, which is the pump re-walking an entry
whose ops were already recorded complete for this identity (entry_replay =
same && slot_ops_complete). The re-mark therefore un-completes a slot whose
copy HAS run: the next pass is fresh, re-executes the op, the next pin-batch
rewind re-marks it again - a replay/fresh/replay cycle that re-arms a 3 s
opdef hold every round and stalls the whole copy channel behind it.
Measured: 100% of the op_tr_pending marks in the r604-r609 boots came from
replay passes (27/27 in r609; 71/71 in r606, whose captured held chain
idx=90/92 is this shape; 72/72 in r608). In the r609 boot the d_b H2D entry
(idx=94) was re-marked and re-run every ~0.3 s from 368841 while the vadd
launch waited on it; the launch then hit the r586 fail-closed cap at 15 s
and the engine never wrote (VADD bad=32767 csum=0).
r308's rationale for the replay re-mark (pre-r595 the eng==0 copy channel's
fresh passes never admitted ops, so the re-mark was the only retry hatch) no
longer holds: r595's cap_trust admission runs a plausible copy on its fresh
pass, and a genuinely failed copy keeps its slot incomplete via op_owed / the
svc_run_ops rc!=0 pending rule. The whole denied accounting block (dstpend
note, staging re-snapshot, pending mark, hold) is now skipped on replay; a
fresh (non-replay) denied pass marks exactly as before.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
held-chain serialization
The m169 device-dst first-touch window is per PAGE, but the risk it covers
is per client table build. The driver's H2D relocation burst on the eng==0
copy channel writes N distinct first-write pages back to back; because the
pump holds the first held entry and the rest of the chain decodes only after
it drains, each page paid its own 3 s window, serialized (r606 red draw:
hold idx=90 362167.7->362170.8, idx=92 362177.7->362182.9, the b H2D entry
ran 362182.882, 326 ms AFTER the launch forward -> VADD bad=32735
csum=8139264, c = a + 0).
Every observed release logs 'without a pin': the pin the window waits for
never arrives for this class. After ONE un-pinned release on a channel, age
it (gsp_sema_copy_dst_age_ms, default 3000): further first-write device-dst
pages of that channel inside the window run immediately with the walk
translation - the exact translation the expired guard would have used
anyway. The first page of every burst still pays the full window; only the
N x window serialization is removed (~20 s of chain -> one window).
Keyed by h_object like every channel table and cleared by the session
flush (svc_dst_guard_reset; also clears the per-page slots, which are keyed
by VA alone and must not pre-age the next client's first touch - the r604
lifetime lesson). 0 restores per-page windows (pre-r609).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
engine_type!=0 (final form of r590b, on the r606 red-draw capture)
The r606 fresh-boot first mail client drew the classic red VADD
(bad=32735 csum=8139264, c = a + 0) with the peek armed, and the capture
names the blindness exactly:
362177.927 GR-DEC push=0x20043c394 dropped=9 partial=1 dstpend=0
copypend=0 ceback=0 defer_exp=0
362178.001 peek-backlog h=0x5c000059 eng=0 put=95 last=92
362182.145 peek-backlog h=0x5c000059 eng=0 put=95 last=92
362182.556 GR LAUNCH submitted (one-shot arg-defer retry)
362182.882 ce-soft-copy va=d_b executed - 326 ms AFTER the forward
-> VADD bad=32735 csum=8139264
The driver's H2D relocation copy sat three entries behind on the
COMPUTE-class channel h=0x5c000059 (eng=0) for 4.7 s, held by
'sema-pend: hold h=0x5c000059 idx=90 ... (operand pending)' - the wait
group (0x20480fff0 pay=84) passed every pass, so the only guard blindness
was the engine_type filter: ceback=0 while the copy channel was provably
behind. The r590 watermark now considers every other channel of the
device (the launching channel itself is excluded: its ring legitimately
runs ahead with future entries). Same pass snapshot, same bounded
busy-defer; this guard never refuses - the r586 fail-closed branch is
separate and fires only when argument pages never resolve. r595's
GR-class ops admission has since cut hold resolution to 0.5-4.7 s (the
captured 4.7 s), well inside the 15 s cap, so the deferral ends by
forwarding with the copy executed.
Companion to r605 (newest-registered-first walk within the class): r605
drains consumable published entries before the launch decision in the
same pass; r607 defers the decision while any other ring still holds
unconsumed entries (held chains included).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
stream-order fix completed (the write-pointer drain, by ordering)
The r507o stream-order fix (walk CE channels before GR ones) assumed the
client's H2D copies ride CE channels. r595 established they also ride the
compute-class channel h=0x5c000059 (eng=0), and r604 gave the decision-time
capture: at the vadd's second decision on a fresh boot,
'peek-backlog h=0x5c000059 eng=0 put=95 last=94' - the b-copy entry was
already written and PUBLISHED (GP_PUT ahead of the pump) while the launch
decision ran, invisible to every guard (the r590 watermark skips
engine_type==0; the r541/r568 gates only see DECODED copies). The pump's
stable partition walked the launch channel (registered early, 0x5c000019)
before the copy channel (registered later, 0x5c000059), so the copy was
consumed 8 ms AFTER the decision and ~320 ms before the launch's copy-in;
the run was green only because the partial-argument defer had stretched
the window. Pins landing one pass earlier would have forwarded against
the pre-copy page (c = a + 0, the r568 red draw).
Fix the order within the class: newest-registered first (descending
h_object) walks the driver's later-registered copy / push-library channels
before its compute channels, so every launch decision sees the copy ring
consumed to its live write pointer (GP_PUT) - the write-pointer drain, by
ordering. No deferral, no cap interaction, no speculative execution: the
pump still consumes each entry exactly once through its normal per-slot
identity bookkeeping (slot_ops_ident/done/complete/hash), so no identity
mirroring is needed. A client whose compute channel registers last keeps
the historical order (no worse).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
set incl. eng==0 copy channels
Two fixes, both from the SESSION 49 r603-family capture.
1. The r543 arg-defer latch and the r556 absolute defer cap are keyed by
push VA ALONE, and the UVM pool reuses the same launch push VAs for every
client of a boot - the exact lifetime bug the session flush already fixes
for the r565 exactly-once memories (svc_gr_cap_hist etc.). Carried across
sessions, the r556 stamp armed once at the previous client's first
sighting, so a new client's first decision for a reused VA already read
defer_expired()=true: every partial-argument defer failed closed (r586
path: QMD release authored in software, no engine launch) and the client
read stale/zero buffers. Witness (r603-family boot): the first mail
client (fresh VAs 0x20043be94/0x20043c364) deferred and launched (GUEST
GR LAUNCH OK ok=1/ok=2); every later mail client (VAs
0x20043beac/0x20043c37c reused) saw defer_exp=1 at its FIRST decision
with GR forward REFUSED at defer cap for both launches, and its 'green'
was the previous client's results still in the reused device pages.
Reset both tables with the session; within a session the original
bounds stand unchanged.
2. gsp_phys_gr_peek now logs every drained channel (cap 8 -> 24; the six
CE ranks came first and always spent the cap, so the eng==0
copy-carrying channels were never in the logged set - Session 48's 'the
copy channel's lookahead read empty' was an artifact of that), names the
channel's engine_type, deepens the lookahead to 6 slots, and logs
peek-backlog rows for channels whose live GP_PUT reads ahead of the
pass's consumed position (the r590 watermark skips engine_type==0, so a
published backlog on a GR-class copy channel is invisible to every
existing guard; the capture must show it).
r604 evidence (fresh boot, peek armed, mail first client): both launches
ran (ok=1/ok=2) and green; at the vadd's second decision
'peek-backlog h=0x5c000059 eng=0 put=95 last=94' - the driver's H2D
b-copy entry was already written+published on the eng==0 copy channel
and unconsumed, executed 8 ms after the decision and ~320 ms before the
launch's copy-in; zero write-ahead (+j) rows at any decision.
|
| |
|
|
|
|
|
|
|
| |
The r568 lever is the driver's ring WRITE pointer, not the GPFIFO put:
the b copy entry exists in the ring before the client publishes GP_PUT.
Add a bounded diagnostic (gsp_phys_gr_peek) that, when a channel reads
as drained, dumps up to four slots past last_get with {va,len} and
whether the slot already executed that exact entry - so the next fix can
be grounded in what is actually written ahead of the put.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
of the rebuilt window (default off)
The verbatim prelude replay breaks the launch (r599: qmd_rel=0 after an
8.9 s stall), so the acquire cannot be taken by replaying the prelude.
This takes only the wait method groups - C46F addr 0x5c count>=5 with
EXECUTE&7 != 1, and C5C0 SET_REPORT_SEMAPHORE A..D with a non-release op -
and copies them verbatim before the proven init+window+PCAS+release
block, leaving the window untouched.
Gate: gsp_phys_rmcall_gr_acq (default 0). Live A/B on r601: the mail
launch's prelude carries ZERO acquire groups (the C5C0 prelude is inline
parameter data + release only), so emitted=0 and the VADD race is
unchanged - the driver assumes its relocation copies precede the launch
without an engine-visible wait.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The r595 A/B could not be judged from the log: with prelude=1 the r593
boot never reached the build path (r590b deferred first) and no
geometry line existed. Print raw presence/raw_words/hdr/end/want_end for
the first eight prelude-gated launches so the gate is verifiable.
r599 measurement: raw=1 raw_words=210 hdr=138 end=205 want_end=205 -
the gate IS met; the verbatim prelude is replayed (words=205) but the
launch then completes with qmd_rel=0x00000000 after an 8.9 s stall
(engine never ran; software release), so prelude=1 breaks the launch.
|
| |
|
|
|
|
| |
ring, not engine_type!=0""
This reverts commit 668c22768abce559ab756f2f998260e08044a3d1.
|
| |
|
|
|
|
| |
forward (never refuse)"
This reverts commit 9333e84deed78464a7448c9faaf6841261a802d8.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(never refuse)
With r595 the relocation copies execute within 0.5-1.5 s, but the r590b
watermark deferred through the shared 15 s cap; by then the r541/r583
dstpend guard took its fail-closed branch and refused a launch whose
data was already on its way (r596 mail MAILDUMP zeros, 2 refusals).
Track the settle start per push VA and defer only for
gsp_phys_gr_cewm_settle_ms (default 2000). Each deferral is one pump
pass and the pump drains the copy rings before the launching channel, so
the window is enough for the r595 copies; after it the launch forwards
with a witness. The guard can no longer reach any cap-refusal branch.
|
| |
|
|
|
|
| |
not engine_type!=0"
This reverts commit 64cca43699d6b74a1f2f2c5e087d33c7aba59de1.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
copies live on a compute channel
The r568 b-copy class is rooted in the op gate: allow_ops was
(ch->engine_type != 0), so a GR-class channel's own memory copies
(LAUNCH_DMA on h=0x5c000059, eng=0) never executed unless the push page
came from an injected pin. Their releases were still applied by the
op-hold path, the client's blocking cudaMemcpy returned, and the launch
read the pre-copy page (c = a + 0).
Admit ops when the push content is a plausible method stream - the same
content arbiter (cap_trust) that already gates GR launch capture - never
on a replay or a rehold. Measured: the d_a/d_b relocation copies now run
~0.5-1.5 s after the driver submits them instead of tens of seconds.
|
| |
|
|
|
|
| |
engine_type!=0"
This reverts commit f3225a81ca384248180d77f78c3614c73dcf289d.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
engine_type!=0
The r591 draw reproduced the r568 signature (VADD bad=32735 csum=8139264,
c = a + 0) with ceback=0: the driver submits its relocation/H2D copies on
a COMPUTE channel (h=0x5c000059 registers eng=0), so the engine_type
filter skipped exactly the backlog the guard exists for.
Consider every other channel of the device (the launching channel is
excluded: its own ring legitimately runs ahead with future entries), and
read each one's live USERD GP_PUT against this pass's consumed position.
r590's validated part is unchanged: same pass snapshot, same bounded
defer, historical forward at the absolute cap (never a refusal).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
this pass's consumption before forwarding a launch
The r589 mail VADD drew c = a + 0: the h_b H2D entries sat behind a
translation-held CE entry while the pump's last read of the ring's
GP_PUT was 92, so the GR launch (processed later in the same pass)
forwarded against the still-zero b window. The r541 guard needs a
decoded copy and the r568 opdef gate needs a decoded hold; an entry the
pump has not reached yet is invisible to both.
Record this pass's channel snapshot (CE channels first), read each CE
ring's live USERD GP_PUT at the GR decision, and defer while it differs
from the snapshot's consumed position. Both sides of the comparison come
from the same channel and the same pass, so it cannot reproduce r588's
stale-epoch over-fire; the guard only defers (bounded, witnessed) and at
the absolute cap the historical forward stands, never a refusal.
|
| |
|
|
|
|
| |
(stream-order)"
This reverts commit c88a7f6b2658ea2d49b67cd63179a5a1fbce3663.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The r568 copy-pending guard in svc_gr_request could only see decoded
state: an active entry hold (svc_copy_pending) or a recorded device-write
target (svc_dstpend_overlap). A CE copy entry sitting BEHIND a
translation-held entry in the ring has neither - it was never decoded -
so copypend read 0 while the ring still owed that copy. A GR launch
decoded in that window captured the copy's destination before its data
landed: r587 mail VADD computed c = a + 0 (h_c == h_a exactly: bad =
32735 = 32768 - 33, the count of i where b[i] == 0; csum = sum(a) =
8139264), because the d_b H2D bigcopy executed after the launch's
copy-in.
Extend svc_copy_pending() (now per-device) to also report a CE channel
whose ring has submitted-but-unconsumed entries (last_get != put_prev -
the same outstanding relation the completion publish uses). With the
r507o CE-before-GR pass order the CE channel's write-back for the pass
has already run when the GR decision reads it, so the guard defers
(bounded by the existing defer/expiry machinery) until the ring drains
and the re-fill captures the post-copy pages.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the r543 argument defer cap
Two halves of the staging-pin coverage class (r584/r585 boots):
1. guest_pin_stream demand handler: resolve_va_by_content rejects any VA
outside the CE pushbuffer window (PB_CE_LO..PB_CE_HI), so the demands
for the GRFILL dropped staging pages (high client VAs like
0x703304e00000) were silent no-ops - no pin ever landed and the fills
kept dropping them. r586 falls back to the client's own pagemap
(scan_range on the exact page), the same walk the window scans use.
2. vgsp-work: the r543 argument-defer cap expiry now takes the r583
fail-closed path instead of forwarding: the r585 boot's saxpy was
forwarded with n_data=969 dropped=7 partial=1 at the cap and read
stale operands (bad=1047527 csum=130523290); the r584 matmul
(n_data=2 dropped=18) reached the r564 degenerate refusal. Refuse,
author the QMD release in software (rel_done latched), consume,
witness. The dropped pages were demanded first (r585), so the retry
window had its chance; a launch that would run with unresolved
operands is never silently forwarded.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
staging-pin coverage class)
The r584 boot's matmul draw: GR-DEC push=0x20043be64 n_data=2 dropped=18
partial=1 stalled=1 -> the r543 argument defer expired -> r564 degenerate
refusal -> SW completion -> MATMUL bad=65536 csum=0. The dropped pages
(the client's staging buffers 0x71b662c00000/c40000/c80000,
0x7dd0cac00000, kind=a) had NO injected mapping: the host pin stream's
demand loop only parses "stalled VA #N: 0x..." lines, and the GRFILL-DROP
line format is invisible to it - so the fill's retries never saw pins and
the launch was SW-completed without running.
r585: svc_log_stalled_va() for each dropped page (up to the 4 detailed per
episode; the helper dedups per boot and the episode marker bounds the
rate). The host demand loop (<=3 s) then pushes the VA to the guest
scanner, whose pin lands inside the launch's bounded defer window on the
retry - the demand path that already heals every other unresolved-VA
class, now connected to the fill drops.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
structurally (the last per-draw GREEN blocker)
The r583 boot's fail-closed refusal traced to a fill that never executes:
the CE channel-setup push's 8 KB zero fill to out=0x204820000 decoded fine
(type=0 op, dma=0x586, line=8192, value=0) but its EXECUTION resolved the
window VA through the generic chain (pin -> ledger -> translate), which
answered SYS with a stale landing pa=0x1300b0000; the r369 below-floor
guard then refused it ("LOWFILL-REFUSED ... below-floor fill resolved
outside vidmem"), the fill never ran, its DSTPEND note stayed live
("DSTPEND note va=0x204820000 type=0", dma-trace denied every pass), and
every GR launch touching that page deferred to the r556 cap and (since
r583) took the fail-closed no-write path.
The vidmem window is offset-mapped by construction (SVC_VIDMEM_VA_BASE
0x200080000 rationale: the client's vidmem VAs are its window base plus
the vidmem offset into the emulated BAR1 buffer; the same convention
svc_lookup already applies). svc_fill_1d now resolves a VID-aperture fill
whose destination is a window VA structurally - addr = VA - window base,
aperture VID - so the existing contiguous shadow-write block executes it.
Witnessed once per boot ("sema-lowfill-window va=... -> fb offset ...").
No guest page table can express the window offset; the structural rule is
faster AND safer than the stale-looking generic chain.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
has an unexecuted device write
The r581 boot's saxpy red draw (bad=524121 csum=874874129) shows the
residual hole of the r541 dstpend guard: GR-DEC "push=0x20043c198
n_data=2505 dropped=8 partial=1 dstpend=1 copypend=0 defer_exp=0" and on
the final dump defer_exp=1 - the launch overlapped a page whose device
write had never executed (live dstpend records 9.5-85 s old), the guard
deferred through its bounded retry, the r556 15 s absolute cap expired,
and the historical path forwarded the launch anyway: the engine read the
known-stale operand and produced the ~50%-wrong result.
r583: at cap expiry with the overlap still live the forward is REFUSED.
Fail-closed: the candidate's QMD completion is authored in software
(forward-only; rel_done latched so the consume tail cannot double-author)
and the candidate is consumed without an engine launch - the client
completes, the engine never touches a page whose writer did not run, and
the event is witnessed loudly ("GR forward REFUSED at defer cap ...").
This cannot hang the guest: the refusal consumes instead of holding.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
latency root cause)
The r581 boot's guest scanner died mid-boot with ValueError in main():
"invalid literal for int() with base 16:
'0x20400f000\\n0x121000000\\n0x12000ab4c'". A guest-agent transport-escaped
append merged demand VAs onto one line with literal backslash-n, and the
old parser crashed on it. The crash stopped ALL new pins; the host only
re-asserted known pairs, so the UVM pool VA 0x121000000 never arrived
while 185 other injections flowed - the pool-pin latency that blocked
every validation boot.
* pin_gr_stream._demand_send/_demand_loop now write one "echo <va> >>"
per VA (no newlines, no backslashes in the transported command; immune
to transport escaping).
* guest_pin_stream's demand parser extracts every 0x token with re and
skips malformed ones instead of raising out of main().
|
