summaryrefslogtreecommitdiffstats
path: root/kernel
Commit message (Collapse)AuthorAge
* vgsp-sema: SESSION 140 the n_data wiring - QMD-page note, qmd-ptr candidate ↵Arthur Hanson Rasmusson15 hours
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | seed, pin-aware scan reads Three corrections that take the GR fill from 'no candidates' to the launch's real pointer set: 1. Note the QMD page itself into the request's page list (word 34) so the 32..48-even bank scan covers it - the pointer VALUES live inside the QMD (r790: word 34 = 0xdff0febc00) and were never scanned. 2. Seed the fill's candidate set directly from the launch's own QMD pointer pairs (gr_qmd words 34..47, decoded from the push's inline-QMD run): r793 'sema-gr: qmd-ptr seed va=0xdff0feb000 (word 34)' - the values need no page scan (the pages' shadows read empty; the invisible -vidmem-write class). 3. Read the scanned pages pin-aware (svc_read_va first, host mapping of pp->pa as fallback): the push-buffer discovery's pinned staging copy holds the content the decode reads; a raw mapping of the vidmem pa sees zeros. Verified r793/r794: candidates now appear (fill cand n=1 with the QMD window page seeded); the page is correctly classified launch-internal by the R3 hygiene filter (n_data stays 0 - nothing external to relocate for this launch). With the r564 degenerate-set guard bypassed (min_data=0), the forward ENTERS the backend and oopses in gsp_phys_backend_guest_gr_submit+0x4394 ('Oops: 0000 [#2]', workqueue gsp-phys-work svc_fwd_work_fn, NULL-base table walk CR2=0x1e93c R14=0) - the empty-set path needs that guard before min_data=0 can be used. This launch's QMD declares exactly one pointer pair, and it names its own QMD window: a launch with no external data is legitimate and the refusal class must not treat it as degenerate.
* vgsp-sema: SESSION 139 GR fill: reject float-shaped scan words + scan the ↵Arthur Hanson Rasmusson15 hours
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | deduped word-48 page Two evidence-based corrections to the launch-data candidate scan: 1. Float-shape filter at all four scan sites (the three page scans and svc_gr_scan_cand): a word whose f32 exponent byte is in ~[0x6c..0x8f] (2^-19..2^16) is a plausible float scalar, not a device VA - device VAs (2^28..2^47) as f32 land in subnormal/tiny exponents. Root evidence (r789): the launch param page carries the kernel's scalar arguments (0.2f, 640.0f, 480.0f at +0x630 - the 640x480 viewport) and 0x43f00000 = 480.0f was the fill's ONLY candidate - an unresolvable "arg base=0x43f00000" that drove the fail-closed diagnostic and the demand-loop noise for days. After the filter: 'fill cand n=0' (r790) - no false candidates, no false demands. 2. The bank-page scan now covers word 48: the QMD pointer-region pair can name a 4K page that also carries the program pair (r788: ptr[0] 0xdff0febc00 word 34 shares its page with prog 0xdff0feb900), and svc_gr_page_note dedupes the first note (the program's, word 48), so the old 32..47-even filter left that page unscanned. The remaining wall is content, not wiring: with the false candidates removed the launch still refuses (n_data=0 vs min 16) because no scanned source holds real device pointers - the param page holds scalars, the QMD window page reads zero (its content would arrive via the driver's i2m/LOAD_INLINE_DATA writes whose payloads are not in the push), and the inline payload is the driver's zero stub. This matches the SESSION 130 zero-buffer finding and leaves the never-queued i2m copies (or the real GPU path) as the only content sources.
* vgsp-sema: SESSION 138 GR request-builder page-list + fill-candidate witness ↵Arthur Hanson Rasmusson15 hours
| | | | | | | | | | | | | | | | | | | | (sema_dbg-gated, bounded) The dstpend/n_data frontier needed the launch's actual wiring. Prints, once per launch within a bounded budget: the candidate handle, param_va, prog_va, n_pointer + the QMD pointer pairs, the inline-rec count, and the resolved gr_pages list (va/pa/ap/qmd_word); then in the fill, the built candidate set with the arg flag. First capture (r788, Vulkan launch h=0xbeec0100): param=0x4b86000 -> page pa=0x386000 ap=2 qmd_word=32; prog=0xdff0feb900 -> page pa=0x56b000 ap=2 qmd_word=48; ptr[0]=0xdff0febc00 word=34 (DEDUPED into the qmd_word=48 page - same 4K page - and that page is never scanned by the fill's word-32/32..47-even passes); the fill's only candidate is 0x43f00000 (arg=1, from the inline bytes) which resolves in NO vaspace (rc=-2 in all four) -> n_data=0 -> the backend's min_data=2 refusal. The param/prog/QMD-window pages read all-zero in the vidmem shadow on this boot, so the launch's data/code bytes exist in no host-visible source.
* vgsp-sema: SESSION 135 CE first-submission capture: reject a consumed-state ↵Arthur Hanson Rasmusson16 hours
| | | | | | | | | | | | | | | | | | | | | | | | USERD candidate (get >= put > 0) At the first-submission instant the channel's own submission is by definition unconsumed - the notifier clear this capture runs before is what would let the driver treat it as consumed. A candidate whose USERD reads a consumed state (put == get > 0) cannot be this channel's live just-submitted work. Observed r785 (CUDA-first boot, three Vulkan runs): the capture latched fb 0x80000 / userd 0x90000 for beef0101 (rank 0) with put=1 get=1 - the dead CUDA client's caf00012 block surviving in VRAM after its session ended. The decoded entry (va=0x120000000 len=40) was the old session's, the expectations seeded from the stale pool word (want=2/3 vs pay=1) and the Vulkan client stalled into its fence timeout on every run. All genuine first-submission latches on record read put=1 get=0 at the capture instant (r779 caf00012 rank0, r785 caf00012 rank0, r781/run1 beef0101). Idle 0/0 stays acceptable per svc_userd_probe's own rule. Session-scoped rank ownership (svc_ce_firstsub_off) does not cover this class: the stale block belongs to a previous CLIENT, and its consumed state is the only local signal that it is not this submission.
* vgsp-sema: SESSION 134c rank-aware CE first-submission capture - the ↵Arthur Hanson Rasmusson17 hours
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | rank-blind first-hit latched rank 0's block for rank 1 The SESSION 134 first-submission capture scanned the shadow from offset 0 and took the first ring-shaped page for EVERY CE channel. On the r779 boot that latched rank 0's block (fb 0x80000, userd 0x90000) for rank 1 as well (both rows scan_hits=1 latch=1 off=0x80000), so caf0001d's first release was decoded from rank 0's ring/page (sem word +0 instead of +4) and stale-dropped (cur=1 already from rank 0's applied release). The client's rank-1 tracker wait never completed: victory_mail spun at 100% CPU with pub_calls=0 on three consecutive boots (r777/r778/r779), while the r746-era module (25523f84) passed the same run on a fresh boot (VADDs OK, STATUS OK). Fix: try the rank's convention offset (0x80000 + 0x20000 * rank) first, scan the rest bounded as before, and never accept an offset another CE rank already latched this session (svc_ce_firstsub_off[], reset per session). A rank whose block is not in the shadow at the instant stays unlatched for the regular per-pass CE latch instead of stealing a foreign block. Verified on r781 (fresh boot, same params xlate=1/util_scan=0/vas_cand_ms =5000/ce_grace=20000): caf00012 rank0 -> fb 0x80000 upa 0x90000; caf00001d rank1 -> fb 0xa0000 upa 0xb0000 (correct block, sem +4 applied: pool-wr va=0x121000004 cur=0 -> val=1 ok); ranks 2-5 -> 0xc0000/0xe0000/ 0x100000/0x120000 each +0x10000; r780 (r746 module) control run: same client PASSED (VADD n=32768 bad=0 checksum=12204516.000000, STATUS OK); r781 client progressed with pub_calls=185132+ (no spin stall). Also the Vulkan client's CE channel latched via the classic autopin on r781 (beef0101 -> fb 0x80000, live entry0) - first time in the SESSION 131-134 window - confirming the latch machinery works once the wrong-block mis-latch no longer poisons the channel.
* vgsp-sema: SESSION 134b fix the CE first-submission scan's entry decode (u32 ↵Arthur Hanson Rasmusson18 hours
| | | | | | | | | | | | hva truncated the 40-bit VA so no CE-window entry could ever match) hva must hold the 40-bit push VA (bit 32 set for the CE window) but was declared u32 in the scan, so ((h1 & 0xff) << 32) truncated to the low dword and hva < 0x120000000ULL was always true - scan_hits stayed 0 by construction. Same decode as svc_chan_userd/svc_gr_ring_candidate (u64). Verified building; the FB-convention latch itself (auto-pinned ring h=0xcaf00012 -> fb 0x80000, userd 0x90000, entry decode + push decode, ops_runs=1) was observed independently on r776.
* vgsp-sema: SESSION 134 CE first-submission capture + bounded completion hold ↵Arthur Hanson Rasmusson19 hours
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - the CE ring latch instrument The CE-class ring (the SASS-delivery channel's GPFIFO, registered at gpfifo=0x4100000 on every boot) only ever latched on one boot (r763, the FB convention matched shadow 0x80000 and the sweep decoded the inline LAUNCH_DMA entry). On r765-r775 every deterministic source reads a zero page (the page tables genuinely map the ring VA to an all-zero RAM page - proven by the per-level walk trace) and the ring never appears in the shadow (scan_hits=0 at the submission instant; dump_vidmem map shows only the USERD put words) nor in the guest RAM image (a full 4 GB scan for consecutive GPFIFO entry pairs around the CE push window finds none). New bounded instrument, default-inert: - svc_ce_firstsub_capture: on a CE channel's notifier clear (the one instant ring content and USERD are both live), before the clear write: reads entry0 through the channel translation and the trusted walk, then scans the shadow (0x100 step, 64 MB) for a CE-window ring page (1MB-aligned push VA in [0x120000000,0x121000000)) and latches via the standard USERD gate at +0x10000/+0x2000/+0x1000/+0x0. Budget 4/channel, 16 witness rows/boot, reset by svc_session_flush. - sema_ce_hold_ms (module param, default 0 = off): holds an unlatched CE channel's notifier busy for up to N ms so the guest keeps the submission in flight (and with it the ring content) while the VAS lands and the regular per-pass latch path retries; expires into the old clear behaviour. r774/r775 evidence (sema_ce_hold_ms=8000): sema-cefirst at the first submission shows rrc=-2 (no VAS yet at +0.2 s), wrc=-1 (walk unresolved), scan_hits=0 (no shadow ring); 30 s later the walk answers a zero page (rpa changing per boot, e0=0x0), the hold expires unlatched, and the client still completes (VKFRAME_DONE) - the hold is safe but the ring's write path is still not visible to the emulation. Remaining unknown is named: the driver's ring writes reach neither the shadow nor the PTE-mapped guest page.
* vgsp-sema: SESSION 133c USERD-shape-derived ring pass - find the channel ↵Arthur Hanson Rasmusson19 hours
| | | | USERD by its own shape (put@+0x8c, get@+0x88, the find_userd layout) and derive the ring at userd-{0x10000,0x2000,0x1000}, validating entry0 (shape + not provably dead) and the USERD probe; the USERD words appear at channel creation and stay while the ring entry may be written later, so this is the stabler trigger for the CE-family rings that the periodic ring-entry scan misses
* vgsp-sema: SESSION 133b shadow ring scan - step 0x100 (the rings are ↵Arthur Hanson Rasmusson20 hours
| | | | unaligned: r767 USERD shape scan found the channel blocks at 0xfee00/0xff000/0xff200, so the rings sit at offsets like 0xefe00) and retry rate-limited (1.5s) instead of a consumed once-bit, because a first pass can run before the client has written the ring or its USERD
* vgsp-sema: SESSION 133 bounded shadow ring scan fallback - the CE-class ↵Arthur Hanson Rasmusson20 hours
| | | | rings live in VIDMEM and the FB convention only matches when the guest VRAM allocator happens to place them at the conventional offsets (r763: matched fb 0x80000/0xa0000 and the CE channel decoded its inline SASS copies; r765: read zeros, the ring VA resolved to a stale RAM page whose entry0 was dead, the CE channel never latched - black frames). When every deterministic candidate fails, scan the first 64 MB of the shadow for a ring-shaped page (entry0 names a 1 MB aligned push VA in the client window with a sane length, not provably dead via svc_ring_entry_dead) whose USERD at the observed deltas (+0x10000 CE family, +0x2000 GR, +0x1000) reads a coherent put/get; one scan per rank per boot, re-armed per client session. A false candidate still costs only a failed probe.
* vgsp-sema: SESSION 132 ring-latch truth + per-client util witnesses - the ↵Arthur Hanson Rasmusson20 hours
| | | | r759 false positive is fixed at three points: (1) a ring candidate whose entry0 push provably reads all-zero through the client's own page tables is rejected when the VAS walk resolves the ring VA to a page with a live entry (svc_ring_entry_dead + svc_ring_walk_live, applied at the userd-derived, FB-convention and existing-pin paths; the walk cannot vote for itself); (2) svc_gr_ring_candidate now rejects dead-entry candidates too and accepts the channel's known USERD cross-aperture (r759: ring in guest RAM 0x11623d000, USERD in vidmem 0xb0000, so the walk-resolved ring failed the same-aperture USERD probe); (3) the util sweep arbitrates a dead channel-path ring entry against the direct VAS walk per slot. Also: util-dec/util-sweep witness budgets and their dedup keys become per-client (reset in svc_session_flush) and the sema-copyent witness logs once per copy op instead of per row (a 480-row frame copy alone exhausted the 128/session budget and hid every later copy, including any SASS upload)
* vgsp: dump_vidmem map mode - one line per 1 MB block with non-zero content ↵Arthur Hanson Rasmusson21 hours
| | | | (nz count + first offset) to locate the live client's uploaded regions in the 256 MB aperture without 65536 range dumps
* vgsp-sema: SESSION 130 xlate regression bisect - the r727 translator ↵Arthur Hanson Rasmusson21 hours
| | | | regressions were re-tested on a fresh boot: with the translator ON and the utility sweep OFF, victory_saxpy and victory_math PASS with checksums identical to the gate-off baseline (saxpy csum=981440890.500000), so the SESSION 129/130 sweep changes fixed the saxpy/math half; the remaining xlate-on regression is victory_multikernel, whose physical forward times out repeatedly (GR LAUNCH FAILED ... qmd_rel=0xc0ffee01, hold active), so the default stays 0 until that forward path is fixed. The UTILITY SWEEP is the other regression source (util_scan=24 broke saxpy bad=1047527 and hung math) and stays opt-in until its channel reads prefer the direct walk
* vgsp-sema: SESSION 130 zero-payload application + tail-arbitration witness - ↵Arthur Hanson Rasmusson22 hours
| | | | a zero-headed tail-served payload is now applied under a variant once-key (h | 1) instead of being refused forever (the destination is empty, so authoring zeros is idempotent and correct for the driver's internal zero buffer, whose 256 B i2m equals GF100_ZERO_BUFFER_SIZE exactly), while a later non-zero payload for the same entry still matches its own (h) key and lands; the utildec witness now carries alt=success/tries so a walk-read that fails is distinguishable from one that returns zero
* vgsp-sema: SESSION 130 util-channel LOAD_INLINE_DATA arm FIXED - the subch-2 ↵Arthur Hanson Rasmusson23 hours
| | | | GRCE operand group was swallowed by the TURING-copy branch (its `subch >= 2` guard also matches subchannel 2, leaving have_out/line_len unset so the LID arm never fired: r739 witness `lidn=1 subch=2 saw=0 dst=0 ll=0`); the 0x180..0x18c group now parses FIRST for subch 1|2, plus tail-content arbitration (a zero-headed channel tail is re-read through the direct registered-VAS walk before the arm's zero-refusal can stall the upload) and the witness now carries the served tail's first two words + the alt-read counter
* vgsp-sema: SESSION 129 util-channel LOAD_INLINE_DATA arbitration + witness - ↵Arthur Hanson Rasmusson31 hours
| | | | the subchannel-2 arm never fired (r737 writes=0) because the utility channel's read path could not produce a parseable methods entry (the tail-served split shape); the util sweep now arbitrates attempt A (channel path, unchanged) against attempt B (direct registered-VAS walk, the walk_probe-proven path) and lets the strict parse choose the stream, a still-zero tail-served payload is refused (no once-store, retried every pass; in-push payloads untouched), and a bounded deduplicated sema-utildec witness names per distinct entry: winning attempt, both parses, tail VA/length, LID header count/subch and the arm's saw/fired/zero state
* vgsp-sema: SESSION 128 utility/copy-channel inline-download sweep ↵Arthur Hanson Rasmusson31 hours
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (sema_gr_util_scan, default 0) - decode the driver's engine-side MME/i2m upload path and materialize LOAD_INLINE_DATA downloads and pitch copy-ins from channels the put-bounded entry loop never decodes The Vulkan client's code/constant uploads leave the utility channels (the MEM2MEM/A140 composite at h=0xbeef0100 and the eng=11/12 copy channels) and were invisible to the emulation: with an unresolved USERD the put-bounded entry loop skips those channels entirely (the !userd_ok branch continues), and with a resolved USERD the main decode's operand group and LOAD_INLINE_DATA arms only accept subchannel 1 while the uploads ride the mem2mem/copy subchannels (2/4). svc_gr_util_sweep scans up to sema_gr_util_scan (default 0 = off; requires sema_gr_xlate) GPFIFO entries of every channel directly, reads each push plus its successor as the tail (the driver's source-view GPFIFO call carries the payload of a trailing LOAD_INLINE_DATA run - observed beef0100 idx00->idx01 and idx08->idx09), and feeds them through svc_gr_ahead_push in a new inline-only mode: the GRCE/INLINE_TO_MEMORY operand group now also accepts the mem2mem subchannel, the QMD window, release and copy-pend arms are skipped, and a TURING_DMA_COPY_A launch on the copy subchannels materializes the engine copy-in (src from the client's staging buffer through the trusted read, dst through the same svc_grce_inline_write the GR sweep uses) instead of queueing a launch copy-out. Every materialization is once-only keyed by (push_va, content hash, dst, bytes); SVC_AHEAD_TAIL_INLINE_MAX rises 4 KB -> 32 KB so the 12 KB code-staging payload is not truncated. Verified on r737 (gated): the sweep runs for all ten channels (utility, CE and GR) with bounded reads and no release/QMD state changes; the utility channel is swept 14 entries per pass. The LOAD_INLINE_DATA arm on the utility channel's subchannel-2 runs still does not fire (payload/parse witness is the next debug item, see Handoff SESSION 128).
* vgsp-sema: SESSION 127 follow-up - gate the C5C0 translator behind ↵Arthur Hanson Rasmusson32 hours
| | | | | | | | | | | | | | | | | | | | | | | | sema_gr_xlate (default 0) The r727 full battery with the translator active but ungated regressed three clients (saxpy bad=1047527, math sums=0, multikernel hang) while r729 with the translator's semantics gated off is clean on the same subset (mail, saxpy, math OK; multikernel still stalls in its pre-existing flaky class). All translator behaviour is now behind sema_gr_xlate (default 0 = exactly the historical sweep): - the tail-aware method parse (tail passed only when enabled), - the sweep's inline-QMD accumulation, LOAD_INLINE_DATA materialization, C5B5 copy capture and candidate-owned release withholding, - the client-VAS walk fallbacks in svc_gr_page_note / svc_gr_req_fill, - the inline-rec filter at capture (keeps resolvable or QMD-named recs when enabled; historical keep-all when off), - the pump's sweep-captured-launch request and copy fallback. sema_gr_xlate=1 restores the full translator (r730 re-verified: launch captured, page-notes, copy pend/done, submit refused n_data=0, release authored, client completes). Flip the default once the two CUDA-side hazards (stale-VAS resolution widening, rec-filter interaction) are eliminated and the battery is proven clean with it on.
* vgsp-sema: SESSION 127 C5C0 TRANSLATOR v1 - the Vulkan compute launch ↵Arthur Hanson Rasmusson33 hours
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | captured, filled and forwarded (and its copy-out executed) through the CUDA QMD machinery The Vulkan client's compute dispatch is an inline-QMD launch that lives in the PRE-BUILT ring continuation beyond GP_PUT (the earlier analysis only inspected the put-bounded pushes' idx7/idx12 and concluded 'no inline QMD'): beec0100 idx23 carries SET_INLINE_QMD_ADDRESS_B (0x31c = 0x4b85f, the upper half absent) plus the 64-word LOAD_INLINE_QMD_DATA (0x320) run - grid 40x30, prog=0xdfd8feb900 (the SASS page), param=0x4b86000, release0=0x4b85e08/1 - and idx24 carries the TURING_DMA_COPY_A (0xC5B5, subch 4) image->buffer copy-out (src=0xdfd8d60000 dst=0x050b0000, 640x480 RGBA rows) plus the SEND_PCAS schedule (0x2b4 = qmd>>8, 0x2bc = SCHEDULE). Pieces landed (all service-thread, all bounded/logged): - svc_gr_ahead_push (the sema_gr_ahead sweep parser) is now a strict tail-aware translated decode of one continuation entry: it accepts a method stream whose final inline run is completed from the NEXT ring entry (the driver splits big LOAD_INLINE_DATA payloads into a dedicated data slot entry: beef0100 idx00->idx01 256 B, idx08->idx09 12288 B), feeds the C5C0 inline-QMD window to svc_qmd_accum (capture via the standard CUDA QMD candidate), materializes GRCE/KEPLER_INLINE_TO_MEMORY_B LOAD_INLINE_DATA writes into the VA shadow exactly like the main decode (once-only keyed; recorded in the dst ring for the fill's inline-served pages), parses the C5B5 copy operands (0x400/0x404/0x408/0x40c/0x410/0x414/0x418/0x41c, 0x300 LAUNCH_DMA, 0x700/0x708 remap) into a pending copy list, and queues the release groups minus a release a live launch candidate owns (that word belongs to the completion edge, so the client's fence can never clear on a pre-render image). - The parser reads the run data words correctly (w3 fix; the GRCE 0x18c operand was being read from the next run's header word, which sent the 1568 B parameter-bank write to a bogus destination). - svc_qmd_accum: accept the ADDRESS_B-only inline-QMD form (implicit zero upper half) so qmd_dev_va is real for the Vulkan launch. - svc_gr_page_note + svc_gr_req_fill: resolve a client-VAS page through the registered-VAS walk when the trusted sources do not carry it (the Vulkan QMD's program/parameter/descriptor pages are client-managed vidmem; the fill refused the whole launch with -ENOENT before this). - The QMD capture's inline recs are filtered to the pages the captured QMD names (a stale session-wide rec destination made the fill refuse with ENOENT va=0x80412000 qmd_word=NONE). - Pending GRCE copy-out list executed on the launch completion edge (svc_fwd_hold_gr_release and svc_fwd_outcome_check) before the guest release is authored, with a bounded no-forward fallback at the sweep; the copy itself runs through the standard svc_copy executor (observed: 'copy done h=0xbeec0100 dst=0x50b0000 bytes=0x12c000 rows=480 rc=0'). - The pump offers a sweep-captured launch every pass (svc_gr_request) - the continuation launch's only dispatch path - and retires pending copies when no forward is owed. - gsp_phys_gr_min_data (module param, default 16): the degenerate-data-set refusal threshold is now tunable; the Vulkan dispatch's operand set is a handful of records, not the CUDA-era 968. - Bounded witnesses for the request paths (first-N/periodic: no-candidate, backend-not-ready, hold-busy, inflight-busy, fill-ENOENT) and the capture tail dump is now sema_dbg-gated with a 4/boot budget (it flooded dmesg). Live status (r726, cycles r719..r726): the client runs green through the fence (VKFRAME seq/DONE/IDLE, 3 PPMs) with no in-flight client assist; the sweep captures the launch ('launch captured ... qmd=0x4b85f00 prog=0xdfd8feb900 param=0x4b86000'); the fill resolves the QMD pages (page-note src=walk) and now passes its ENOENT gate; the copy-out executes for every frame. The physical launch itself is still refused: the fill yields n_data=0 because the launch's operand CONTENT (the SASS at prog=0xdfd8feb900, the descriptor data) is delivered by the driver through the MME / inline-to-memory engine upload stream (beec0100 idx7/idx12, beef0100 idx08), which the emulation does not execute - the pages the QMD names stay zero in the emulated vidmem. That engine-side upload path is the next work item; sessions r719..r726, evidence in the handoff. No host reboots; 0 oopses; the fetch of the CUDA battery on a fresh boot follows separately.
* vgsp-sema: SESSION 126 FENCE FOLD - channel-anchored sweep of a GR channel's ↵Arthur Hanson Rasmusson36 hours
| | | | PRE-BUILT ring continuation beyond GP_PUT (sema_gr_ahead, default 64): the live Vulkan client's fence waits never clear because the driver's kick boundary stops at the first batch (put=11) while the ring already carries the continuation entries (12..47) whose INC-5 RELEASE groups target the fence words - r716 ring dumps: beec0100 idx17 0x49035b0 len=1020 (group at +0x374 -> 0x45ba080), idx25/33/41/46 at 0x4903f5c/0x4904594/0x4904bb4/0x49051d4 (len 136/112 -> 0x45ba090), all beyond the GP_PUT-bounded walk; the sweep walks entries beyond put through the ring's validated GPFIFO translation, accepts only entries passing the strict method-stream gate (all fence entries parse), extracts addr-0x5c count>=5 RELEASE/REDUCTION groups and queues them forward-only via the standard pending ledger - no consumption bookkeeping touched, idempotent, gated by gr_pub_armed (live epoch) and rrc==0; also: sema-pushdec budget 512->2048/client (boot-time driver-init reads exhausted it before the client's first submit on r716) and chan_dump gains armed=%d
* vgsp-sema: THE CONSUME-WITHOUT-DECODE BRANCH FIXED - the strict ↵open-iov36 hours
| | | | | | | | method-stream parser rejected the real driver's push shapes (op 0 = NVC06F_DMA_SEC_OP_GRP0_USE_TERT, observed 0x0001fff0 SET_SUBDEVICE_MASK; zero NOP padding mid-stream), so every large GR submit push read implausible and was skipped unread; plus the sema-pushdec branch witness (va/src/pa/plausible/injected/ipin/zero_nop/displaced/unreadable/first8, 512/client), the injected flag now follows the source that ACTUALLY answered the read (src 0 only - a page-granularity ipin lookup could take the injected branch while the read used the trusted walk src 4), the PA of the winning read source is recorded (svc_read_last_pa), and svc_push_prefix_ok accepts the same header-only ops r715 in-run validation (mdev b4ccb179, t122 recipe + content-located PDB anchor via pdbtick + rewind): the 1432/976/17316-byte GR pushes now reach svc_decode_stream (sema-pushall rows) and decode with releases: 'sema-push: h=0xbeec0100 va=0x4ca0f1c len=17316 rel=0x4b17c30 pay=3 have_rel=1', 'va=0x4ca0000 len=1432 rel=0x4923000 pay=1 have_rel=1', 'va=0x4ca059c len=976 rel=0x4b17bb0 pay=3 have_rel=1', CE 'va=0x4d00000 len=204 rel=0x4b19b10', plus the same shape on h=0xbeee0100; service applied=29 miss=0; the release words read back 1 in guest RAM (sema_probe 0x4923000..0x49230a0, 0x4b17xxx, 0x4213xxx all advanced). The sema-pushdec rows name the branch and content on every read (e.g. 'va=0x4ca097c len=4 ... plausible=0 zero_nop=0 unreadable=1 first8=00000000 00000000' for the all-zero 4-byte kicks). REMAINING GATE (session 125): vkWaitForFences still times out (~70 s of the client's 120 s bound, UMD-internal cap) even with all push releases applied - the fence wait word is NOT among the eleven released semaphores (released words verified 1 in RAM; the client's wait does not go through the eglcore+0xDCEBD9 device-wait-word chaser that carries the init wait at +0x80 of a 16 KB nvidiactl BO; 16 blind writes to zero wait-slots did not flip it). Next: enumerate the UMD wait-check helper via the vtable at the 0xDCEBD9 site (checkfn=*(*(void**)rbx+0x18)) and breakpoint it for every wait word, or trace the guest kernel poll(NV_DEVICE) handler for the fence object.
* vgsp-sema: raise the sema-rdw witness budget to 6000/client and log the ↵Arthur Hanson Rasmusson37 hours
| | | | viawalk retry outcome (walk rc, pa, plausibility) - session 124 evidence: for the GR submit push 0x4ca0000 the read returns rc=0 src=4 (trusted) even AFTER the user VAS registers and walk_probe rc=0, yet NO viawalk row and NO decode row appear and the entry skips after ~250 rescues: the entry is consumed between the read and the decode (plausibility passed but the decode never ran, or an earlier branch took it) - next: witness the branch taken after the read (plausibility verdict, injected/zero_nop/displaced flags)
* vgsp-sema: per-client unconditional push-read attempt witness - sema-rdw ↵Arthur Hanson Rasmusson37 hours
| | | | (h/va/len/rc/winning-src, budget 400/client, reset in svc_session_flush) at the pump read site plus the r707x src out-param (svc_read_last_src) inside svc_read_va_push_ex; also per-client reset of the sema-pushfail budget. r713: the run reproduced VKDEVICE+flips+VKFAIL but the witness rows scrolled out of the 2 KB dmesg ring before capture - the next run must read dmesg immediately after the first skips (or raise the ring buffer)
* vgsp-sema: on an implausible primary push read for a GR entry, retry via the ↵Arthur Hanson Rasmusson37 hours
| | | | DIRECT registered-VAS walk (svc_walk_vaspaces + svc_read_ap, the exact path walk_probe proves) instead of svc_lookup_trusted - whose pin/lat hits would answer with the same wrong page again; r711/r712 evidence: the user VAS registers and walk_probe rc=0, the rewind replays, but the retry/log never appears and the entries still skip after ~250 failed rescues (the sema-pushfail witness budget is per-boot and was exhausted earlier, so the read-failure detail was invisible this boot)
* vgsp-sema: every-pass VAS candidate verify with the last-good ring pair ↵Arthur Hanson Rasmusson37 hours
| | | | (r707e) - the r710 boot shows the host content-located trigger registers the user VAS and the walk resolves (walk_probe va=0x4ca0000: vas[3] h=0xfade0002 pdb=0x101d63000 -> rc=0 pa=0x11fa20000), while the pump's own svc_lookup pair only registered the three internal VASes (all rc=-2); the working order is: content-located trigger FIRST (registers the user VAS), then sema_chan_rewind so the replay re-reads the entries with the working VAS
* vgsp-sema (FOLD): verify the parked COPY_SERVER_PDES VAS candidates the ↵Arthur Hanson Rasmusson37 hours
| | | | moment any channel's ring resolves through the channel object, so the user-VAS page directory can register BEFORE the submit's first push reads (the host-triggered path could not win that window: a failed GR entry read is never retried with the fresh VAS); r709 evidence: three VASes registered (h=0xc/0xbaba0042/0xcaf00000, pdb=0x11b8db000/0x11b8e6000/0x11b8ef000) and walk_probe still rc=-2 for the client's push VAs - the registered directories do not cover the user VAS, so the content-pair verify against the ring must still land for that one
* vgsp-sema: bounded channel rewind (sema_chan_rewind: hex h_object or 'all' ↵Arthur Hanson Rasmusson37 hours
| | | | -> clears slot_done_epoch + last_get + the per-entry rescue state so entries skipped before the VAS pdb anchor re-decode) + bounded per-chunk push-read failure witness (sema-pushfail: va/chunk/page/last_rc/trusted_rc/ipin/alt/win per failed chunk); wall2: runbook.py (trigger the anchor then rewind). Session 118: the anchor+rewind path is wired; the automated rewind scheduler missed (dmesg churn) and the pushfail trace still needs one clean capture
* vgsp-sema: host-triggered VAS pdb discovery (sema_pdb_discover va,pa -> ↵Arthur Hanson Rasmusson38 hours
| | | | verify the parked COPY_SERVER_PDES candidates against a content-verified ring pair, then fall back to the vidmem walk-root sweep) + runtime-tunable candidate age-out (sema_vas_cand_ms; the default 15 s ages the client's VAS candidate out exactly when its channels first register, so the verified walk can never anchor it by itself)
* vgsp-rm: FB_GET_INFO_V2 COMPRESSION_SIZE reports a comptag pool ↵Arthur Hanson Rasmusson40 hours
| | | | (wall2_fb_compr_mb, default 128 MiB) - the guest driver attempts a COMPR-enabled 64 KB-aligned comptag allocation (vendor VidHeap alloc attr COMPR=2, r703 live: the last vidheap call returns NV_ERR_NO_MEMORY 0x51) and libcuda maps that to VK_ERROR_OUT_OF_DEVICE_MEMORY (the vkAllocateMemory -2 that gates the first Vulkan frame); 0 restores the historic no-compression reply for A/B
* vgsp-rm: answer the NV04_VID_HEAP_CONTROL enumeration pair ↵Arthur Hanson Rasmusson40 hours
| | | | 0x90960106/0x90960107 (legacy NVOS32 VidHeap API) - libnvidia-eglcore walks three heaps and treats an all-zero reply as 'no memory' (the flag byte at entry+0x30 == 0 skips every heap), so vkAllocateMemory failed -2 without any alloc reaching the emulation; replies are runtime-tunable (wall2_9096_lo/hi/ent_addr/ent_size/ent_type/ent_flag) for a one-boot sweep
* vgsp-sema: bind the scrub slot to the EXACT 4096-entry channel ↵Arthur Hanson Rasmusson40 hours
| | | | (NUM_COPY_BLOCKS) - the >=4096 test also matched every client channel (32768 entries in this driver version), so the pass authored for whichever client channel registered last while the real scrubber's finish payload stayed zero (the vkAllocateMemory -2 gate, r701 live evidence: slot held h=0xbeee0102/entries=32768 and the pass logged 'scrub author put=0')
* vgsp-sema: scrub-pass diagnostics - stash bind/MISS logs (4096+-entry ↵Arthur Hanson Rasmusson41 hours
| | | | channels that fail the userd/va condition were silent), pass idle/read-fail/junk-put logs; the r697 session proved the direct authoring works (fin/host sema advance unblocks scrubCheckAndWaitForSize permanently) but the in-service pass never fired
* vgsp-sema r686: accept the low aperture (>=0x4000000) for GR/GL release ↵Arthur Hanson Rasmusson47 hours
| | | | | | | | | | | | | | | decode in both release forms (0x5c-form and SET_REPORT_SEMAPHORE) The GR/GL ucode init pushes carry their releases on the RM's low aperture (the same 0x4000000-0x4ffffff VA family as the push/ring windows): the live GL init push decodes as rel=0x4b19b10 pay=1 (REPORT_SEM group 200426c0 00000000 04b19b10 00000001 10000000) and rel=0x4b17bb0 pay=3 / 0x4b17e30 pay=1 (0x5c-form 2005c017 04923060 ...), all rejected by the sysmem-only SEMA_VA_LO bound - the NvOgl engine-init wait then spun forever. With the bound relaxed (and the push windows injected via the window-record/memdesc recipe) the releases decode live (have_rel=1, applied rising) and the un-translated ones queue in svc_pending (417 at the observed steady state) awaiting the semaphore-VA translations.
* vgsp-rm r682: register NV01_EVENT_KERNEL_CALLBACK (0x78) and ↵Arthur Hanson Rasmusson2 days
| | | | | | | | | | | | | | | | NV01_EVENT_KERNEL_CALLBACK_EX (0x7E) events alongside OS_EVENT (0x79) The driver's modern nvkms/Vulkan path allocates its per-channel completion events with class 0x7E (nvos.h NV01_EVENT_KERNEL_CALLBACK_EX; observed live as GSP_RM_ALLOC class=0x7e paramsSize=24 hParent=<subdevice> hObject=0xcaf00003 from the second RM client while its main thread sat in the vkCreateDevice wait loop, whose readiness word lives in a /dev/nvidiactl notification page that only an event completion can signal). The event registration scanned the params for hClass 0x79 only, so 0x7E allocations were never registered and their completion wake-ups (post_channel_event/post_all_events) could never reach them. Accept all three event classes; the NV0005_ALLOC_PARAMETERS layout is the same {hParentClient, hSrcResource, hClass, notifyIndex, data}.
* vgsp-rm r680 + wall-2 session-76 forensics: 0x2080a097 reply record-area ↵Arthur Hanson Rasmusson2 days
| | | | | | | | | | | | | | | | | | | | tunables (wall2_a097_count/rec0..rec7, default 0xffffffff = echo) and the evidence set that re-questions the a097 gate The real host RM 0x2080a097 handler (GSP-RM 570.144 control table entry, params 0x490) overwrites params+4..+0x23 with up to four {u32,u32} mode pairs (engine value + a x1000 clock/percent) and the client copies back the first 16 bytes; the tick at eglcore 0xd5e3e0 consumes the second word of the first pair as the per-engine progress (session +0xe104, compared against per-boot config threshold 95 at lib+0x2019320+0xffc with 10/20 bit-history cutoffs). New module params let one boot sweep the record matrix; the r680 sweep (flag/v488/v48c + count/rec matrix incl. progress 100..1000000) changed nothing observable, and hw watchpoints show E+0x150 stays 0x00200000 with no writer over 5+ minutes while the a097 poller is a worker thread and the main thread sits in a 10 s poll() loop on /dev/nvidia0 inside vkCreateDevice. Tools: t75g.py (in-guest gdb state/watch probes), diag76.py (thread bt + address resolution), slots_probe.sh, run75g.sh; README-session76.md records the firmware handler decode and the sweep.
* r679: 0x2080a097 handler with runtime-tunable reply words (wall-2 session 75)Arthur Hanson Rasmusson2 days
| | | | | | | | | | | | | | | | The guest Vulkan client (libnvidia-eglcore) issues RM control 0x2080a097 in a ~1.8 s retry loop while its engine-readiness check stays negative; the bare-metal oracle (same client on the host with the real driver) never issues it, so it is a vGPU-only path (engine type 0xe00101). The handler echoes the 1168-byte in/out record block and applies three module parameters - wall2_a097_flag/v488/v48c - so one boot can sweep reply variants without rebuilding (the client reads params +0x204, +0x488, +0x48c back; file offsets 0xecd45f..0xecd475 in libnvidia-eglcore.so.570.144). Sweep result so far: flag=1 with v488=0 or 1 does not stop the retry; the readiness wait lives in the client's engine loop (0xd6ef40..0xd6f0ab polling byte +0x1b038 of the engine object, recomputed by a91ea0 from engine-state fields), so the missing state is deeper than the reply words.
* r655 diagnostics: dump unknown-RPC payloads and UPDATE_BAR_PDE payloads ↵Arthur Hanson Rasmusson2 days
| | | | (wall-2 forensics aid - the r670 capture proved zero unknown RPCs and no mapping RPC during the client's vkCreateDevice attempts, so these dumps are bounded evidence tools for the next wall)
* r654 FIFO_GET_ENGINE_CONTEXT_PROPERTIES (0x801707): return the real ↵Arthur Hanson Rasmusson2 days
| | | | per-engine context geometry captured from the GSP on the physical backend - the client queries ZCULL geometry (engineId=8) at the end of every vkCreateDevice attempt and the generic all-zero reply failed its ZCULL-context buffer allocation (VKFAIL -3); with the handler the client proceeds through GR_CTXSW_ZCULL_BIND, GR_SET_CTXSW_PREEMPTION_MODE, VRAM allocs and MAP_MEMORY_DMA to the GR channel kick
* r651-r653 display path: DISPLAY_GET_STATIC_INFO reports the ↵Arthur Hanson Rasmusson2 days
| | | | one-head/8-window model (feHwSysCap head-0, windowPresentMask 0xff, numDispChannels 81 for the cursor channel numbers) - live gdb pinned the 0x56 to kdispGetChannelNum_v03_00 requiring windowPresentMask&NVBIT32(instance) for dispChnClass_Win and HEAD_EXISTS for Curs; + INTERNAL_DISPLAY_GET_ACTIVE_DISPLAY_DEVICES (displayMask=1 numHeads=1; dispswConstruct rejected every head against numHeads=0); + NVC370_CTRL_CMD_GET_CHANNEL_INFO reports IDLE immediately (nvRMSyncEvoChannel polls 2s for IDLE after every kickoff)
* vgsp-rm r643/r644: NV0073 display-common shim for nvidia-modeset - report ↵Arthur Hanson Rasmusson2 days
| | | | one head (GET_NUM_HEADS 0x730102, GET_ALL_HEAD_MASK 0x730287, flexible window assignment 0x7302ad) and one static TMDS/HDMI connector on display id 0 (GET_SUPPORTED 0x730107, OR_GET_INFO 0x73028b SOR+SOR_SINGLE_TMDS_A, GET_CONNECTOR_DATA 0x730250 HDMI_A, DFP_GET_INFO 0x731140); the generic all-zero replies made nvkms log 'No heads found on board!' and fail (killing Xorg ScreenInit and Vulkan vkCreateDevice), then fail NoValidDisplays() after the heads were added
* vgsp-sema r640: raise the wait-gate episode extension cap 25 s -> 45 s - the ↵Arthur Hanson Rasmusson2 days
| | | | 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)
* vgsp-sema r638: break the CE-watermark/wait-gate mutual citation - a channel ↵Arthur Hanson Rasmusson2 days
| | | | 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)
* vgsp-sema r635: host-side operand resolution when the scanner misses - ↵Arthur Hanson Rasmusson2 days
| | | | 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)
* vgsp-sema r633b diag: log the hold-engage record set (nrel/va0/pay0/gr) and ↵Arthur Hanson Rasmusson3 days
| | | | 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
* vgsp-sema r633: park a held GR launch's push-level release records and ↵Arthur Hanson Rasmusson3 days
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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).
* vgsp-sema r632: the GR data fill serves unresolved operand pages from the VA ↵Arthur Hanson Rasmusson3 days
| | | | 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
* vgsp-sema r627: the copy-landing parity pass no longer clobbers per-page ↵Arthur Hanson Rasmusson3 days
| | | | | | | | | | | | | | | | | | | | | | 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.
* vgsp-sema r626: sema_no_shadow - A/B knob to disable the VA shadow lane ↵Arthur Hanson Rasmusson3 days
| | | | (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)
* vgsp-rm r623: oserrlog - deliver a synthetic OS_ERROR_LOG (0x1006) ↵Arthur Hanson Rasmusson3 days
| | | | 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)
* vgsp-sema r620: r619's device-VA sem-write witness range used the 1 TiB ↵Arthur Hanson Rasmusson3 days
| | | | 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
generated by cgit v1.2.3 (git 2.39.1) at 2026-10-27 11:36:00 +0000