| Commit message (Collapse) | Author | Age |
| |
|
|
|
|
|
|
|
|
|
|
| |
Add a read-only BAR0 register-liveness probe at
/sys/kernel/debug/vgsp/gsp-phys-reg-probe that prints "name addr value"
for the PMC chip-id/clock gate, PGRAPH status/fault, SKED/HWW and
FECS/GPCCS falcon state, the front-end QMD virtual-window controls and
the GSP context registers, followed by decoded field lines.
Read-only (readl only); additive to gsp_phys_boot_debugfs_init(); no
ladder logic changed. Used to distinguish a clock/power-gated engine
from a halted or running one during a physical cycle.
|
| | |
|
| |
|
|
| |
(compile-verified, untested)
|
| | |
|
| | |
|
| |
|
|
| |
+0x800)
|
| |
|
|
| |
ring-chunk page (compile-verified, untested)
|
| | |
|
| |
|
|
| |
with D)
|
| |
|
|
| |
without it)
|
| |
|
|
| |
golden construct)
|
| | |
|
| |
|
|
| |
without BASE)
|
| | |
|
| |
|
|
| |
0x29c, w63 sentinel
|
| |
|
|
| |
launch diagnostics
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
sentinel diagnostic
- The Tier-2 shadow VAs (0x200000 + page<<21 + line<<16) had no PTE chain
in the engine's table view on the shared-management VAS: pdb_build's
client PD0 spine for the guest scratch PT pool is discarded by the
server's root migration, so every param/program/release/alias leg the
launch rewrites to a shadow VA was unreachable by the engine. Install
each scratch pool window lazily through DMA_UPDATE_PDE_2 (same control
shape as the Tier-1 installer, pool chunk as the leaf PT) the first
time a shadow line in it is consumed; shared VAS only, idempotent via
rmcall_guest_pt_win_mask. m17 confirmed the install is accepted
(pdeIndex=1 VA 0x200000 status 0x0).
- IQ2M sentinel: write 0xdeadbeef to the inline-QMD destination word 0
after the prewrite and report iq2m=ran/not-run in the post-mortem so
'engine stalled before the inline window' is distinguishable from 'QMD
deposited but not executed' without a server capture.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
control offset
- New mode 29 (GOLDEN_EXEC_LAST): identical to mode 28 but skips the
TURING_COMPUTE_A alloc on the client-wired golden channel (every GR object
construct there blocks RM); stage 3 completes with the golden handle
swapped and BIND/GPFIFO_SCHEDULE/token are accepted. Param clamp 0..29.
- Shape bits: bit6 TSG parent (alloc accepted, same no-fetch), bit7 host
USERD control offset 0 (THE FETCH FIX: the server applies the sysmem
userd_mem base directly and ignores the captured USERD_INDEX_VALUE=3, so
GP_PUT/GP_GET live at +0x8c/+0x88; m14: GP_GET advanced 1), bit8
pre-promote compute object (invalid order: RM blocked -110 + NOCAT
0x52a8b04).
- Failure diagnostics: REAL GR SEM FAILED now dumps both candidate USERD
control offsets (ctl and alt).
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
unreadable CE entries
- fwclient mask bit 15 (0x8000): book the PRIV_ACCESS_MAP VA (the FWCLIENT
entry form is init-only; the golden9 form carries the VA at VA_GOLDEN9_PRIV).
Accepted on V6 (status 0), completing the maximal promoted context.
- gsp_sema_service: svc_entry_want_reached() verifies the exact tracking slot
against entry_want before the three unreadable-CE consume shortcuts treat the
entry as delivered; when the slot lags, re-seed the expectation and let
svc_fake_release author or queue the exact slot (UVM registration stall pair
with the pool-VA verified-resolver queue).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
stall fix
- Mode 28 golden execution lane behind gsp_phys_rmcall_gr_promote=28 with a
shape bitmask (gsp_phys_rmcall_golden_exec_shape: ring / entries=8 / sysmem
USERD / USERD size / hObjectBuffer=VAS / skip replay TURING_A) and a USERD
control-offset helper. Finding: the RM-managed golden channel hangs any GR
object construct (-110, no assert) as soon as client submission wiring
(ring or sysmem USERD) is attached, so only the captured server-owned shape
constructs; the machinery is kept for future wiring ideas.
- fwclient mask bit 11 (0x800): send each non-MAIN FWCLIENT promote entry as
its own one-entry control and continue past refusals. V6 acceptance matrix:
PM, PATCH, PRIV_ACCESS_MAP, UNRESTRICTED_PRIV_ACCESS_MAP accepted,
FECS_EVENT refused 0x1f.
- fwclient mask bit 12 (0x1000): golden9 VA-only global bookings (BUNDLE_CB,
PAGEPOOL, ATTRIBUTE_CB, RTV_CB_GLOBAL) accepted on V6; bits 13/14
(0x2000/0x4000): FECS PA-only (refused 0x1f) and FECS VA-only (accepted).
- gsp_phys_rmcall_srv_main_ignore: ignore a server-reported MAIN in the
srv-ctx commit and force the client INITIALIZE_CTX + VA-only fallback.
- gsp_sema_service: pool semaphores never fall back to the learned map; queue
the absolute release via svc_pending_add until svc_pool_pa_resolve
succeeds, and judge pool slots through the verified resolver in
svc_apply_pending and the release decode (UVM registration stall fix).
|
| |
|
|
| |
buffers
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
(IQ2M bisect)
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
The mail kernel's output buffer has no QMD pointer word; the engine reaches
it through a pointer inside the parameter bank, so the Tier-1 refusal at its
high VA killed the launch. Alias-map such a page's guest HPA at a fresh
ladder line and rewrite every matching 8-byte pointer inside the shadowed
copy pages (param/program) to the alias, so engine writes land in the
guest's own page and the guest's DtoH sees them.
|
| |
|
|
|
|
|
| |
The inline-record path appends pages after the pointer pages, so the
adjacent-entry heuristic missed the second param page. Record each
shadowed range (base guest VA, line, mapped PTE count) and extend any
page that continues a recorded range, up to 16 pages per 128 B line.
|
| |
|
|
|
|
|
|
|
| |
The mail launch's param buffer spans two pages but the QMD names only the
base page. The second page has no pointer word, so the Tier-2 shadow path
skipped it and the launch was refused. Map a page with no pointer word that
is contiguous with the previous shadow-mapped page into the next PTE of the
same 128 B fetch line (each line covers up to 16 consecutive 4 KB pages),
keeping the rewritten base-pointer buffer contiguous for the engine.
|
| |
|
|
|
|
|
| |
The mail launch has 8 pointer/QMD pages plus up to two release/sem shadow
lines; the 4-page pool exhausted and refused the launch even with the
HPA-copy fallback. 24 covers the 16-page launch cap plus the two release
shadows.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The M1 forward captured the guest's mail launch but was refused at Tier-1:
the guest's UVM program/param pages live at 0x7d6e... VAs whose 2 MiB window
indices are outside this VAS's PDE range, so DMA_UPDATE_PDE_2 returns 0x1f
and the launch fell back (bridge disabled) with the guest polling.
When the page HPA was resolved on the identity domain, copy the full guest
page into the Tier-2 shadow chunk and rewrite the QMD pointer pair, so
pages the engine only reads need no inline coverage. Release/sem pages keep
their existing direct-alias shadow lines.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GET_ENGINE_CONTEXT_PROPERTIES (REAL GR SEM OK)
The golden replay promoted 0x1000 placeholders for FECS_EVENT/PRIV/UNR and
1-page VA-only mappings for the four 3D globals; the server's own geometry
reports FECS_EVENT 0x10000, PRIV/UNR 0x80000 each, PAGEPOOL 0x20000,
ATTRIBUTE_CB 0x7d7400 and RTV_CB_GLOBAL 0x80000 on this TU104. The girmap
sizes are wrong for the engine's ctx-init access-map copies and the ctxsw
bundle, producing INJECTED_BUNDLE_ERROR + FECS ctxsw TDR on every VAS shape.
fwclient-mask bit 10 (0x400) sizes every promoted buffer from the server's
GET_ENGINE_CONTEXT_PROPERTIES (0x801707), re-spaces the VAs to per-buffer
caps, extends the ctx small-PT pages to six 2 MB windows and promotes the
real sizes. Result (golden9k2): golden promote status 0, FWCLIENT MAIN
promote status 0, stage 3 complete, REAL GR SEM OK sem=0xc0ffee01
GPGet=1 GPPut=1, clean teardown, no wedge.
|
| | |
|
| |
|
|
| |
for the golden channel
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The golden9e ctxsw TDR persisted with capture-faithful FBMEM buffers and
mapped VAs. Source dig: the ladder VAS is IS_EXTERNALLY_OWNED, and on that
path the server's promote defers channel-context binding to UVM (which the
ladder never does), so the engine ctxsw never becomes usable. The real
golden channel runs on the PTETABLE_HEAP_MANAGED golden VAS (client-owned
page tables, not externally owned), which takes the full client-managed
commit path. golden9a/b only failed because that VAS had no page directory:
install the ladder root PDB on the golden VAS via DMA_SET_PAGE_DIRECTORY
before the channel alloc, and bind the golden channel to it.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The golden9c cycle reached the server context init and then the GR ctxsw
timed out (FECS_A/B TDR) with host-sysmem MAIN/PATCH/FECS/PRIV/UNR and
unmapped promoted VAs; the golden9d FBMEM test ran on a boot left dirty
by golden9c and its 0x1f is not attributable. The real golden wire carried
FBMEM (physAttr=4) for every ctx buffer, so:
- allocate PATCH/FECS/PRIV/UNR as server FBMEM (PATCH sized by the engine
geometry query) in gr_ctx_prepare before the PDB build (mode 25 only);
- map PATCH/FECS/PRIV/UNR at their promoted VAs with VIDMEM PTEs in the
same 2 MB window as MAIN;
- move the FECS/PRIV/UNR and VA-only 3D global VAs into that window and
give the PA-backed entries PHYS_ATTR_FB.
golden9d's FBMEM channel memdescs are kept.
|
| |
|
|
|
|
|
|
|
|
|
| |
The golden9c cycle reached the promote commit and hung the GR engine in the
ctxsw wait (FECS_A/B TDR records then a fatal assert). The real golden capture
carried client-local FBMEM instance/USERD/RAMFC/mthd memdescs and FBMEM ctx
buffers; the host-sysmem substitution is the remaining aperture difference.
Allocate one FBMEM block for the four channel memdescs (sliced 0x1000/0x200/
0x1000/0x1000 like the client memmgr) and back the promoted MAIN with the
server FBMEM allocation (VIDMEM physAttr 0x4, VIDMEM PDB leaf PTEs) for mode
25. PATCH/FECS/PRIV/UNR stay host sysmem in this iteration.
|
| |
|
|
|
|
|
|
|
|
|
| |
The captured golden VAS cannot be fully constructed by the ladder: its
COPY_SERVER_RESERVED_PDES (0x90f10106) consumes client-RM-reserved page-table
level PAs that only exist in the real client's memmgr (and are boot-specific).
Bind the golden channel to the ladder's own FERMI_VASPACE_A, which already has
server page tables installed by the DMA_SET_PAGE_DIRECTORY + PDB build, so the
pVAS validation in kchannelConstruct_IMPL is satisfied. hObjectBuffer stays 0
(host sysmem PB is client-local) and the USERD keep the proven V5 memdesc
pairing.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
promote)
Ladder mode 25 reproduces the real 570.144 host client's golden-image
construct on the golden replay handles: captured channel shape (flags
0x00200320, hObjectBuffer 0, gpFifoOffset 0, gpFifoEntries 0x20,
engineType 1, host memdesc substitutions), a single atomic 9-entry
GPU_PROMOTE_CTX on the golden channel (MAIN id0 and PATCH id2 combined,
ids 3/4/5/6 VA-only globals, ids 9/10/11 FECS/PRIV/UNR combined), then
the TURING_A 3D object. The golden VAS/channel/3D object stay alive and
the existing V6 FWCLIENT promote follows on the golden-initialized
GR-instance state; a failed golden step aborts with no retry and no
follow-up promote. The captured VAS COPY_SERVER_RESERVED_PDES control is
implemented gated (fwclient mask bit 8, zero-level no-op form) because
its level PAs are server-internal. Mode clamp/name/help extended to 25;
modes 1-24 unchanged.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The 2026-10-05 16:05 crasher sent an accepted non-MAIN PROMOTE_CTX
(PM/PATCH/FECS/PRIV/UNR) before a MAIN control that failed 0x40; the
writing task then Oopsed in vma_interval_tree_remove with a corrupted
VMA rbtree and module list (host kernel memory corruption).
Restore the reference order (kgrobjGetPromoteIds_FWCLIENT: MAIN first)
and make MAIN-alone the abort point: GPU_INITIALIZE_CTX (mask bit7)
then the single-entry MAIN promote; build and send the non-MAIN entries
only after MAIN commits (or when MAIN is deselected). The previous
accepted-non-MAIN-before-failing-MAIN order is forbidden.
Build is unchanged otherwise; mask 0xbf now reproduces the proven-clean
mask-0x81 shape when MAIN hits the memdesc gate.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
- gsp_phys_rmcall_fwclient_mask (default 0x3f): per-entry selection for the
mode-24 FWCLIENT promote set; bit6 selects the MAIN UVM VA-only shape.
- golden replay: tolerate the client-local system-memory PB step and continue
with hObjectBuffer=0; on-ladder TURING_A 3D object retained best-effort.
Live bisection on the KMD channel: MAIN alone reaches the per-buffer commit
and stops at the engine-context memdesc state; PM-only and PATCH-only are
accepted; any multi-entry control containing MAIN is refused 0x1f. All
cycles release clean.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- golden replay (gsp_phys_rmcall_golden, default off): replay the stock
client's post-load golden channel allocations (separate VAS, pushbuffer
objects, USERD, bare GR channel, TURING_A 3D object) before the ladder
channel; best-effort: a failure warns and the ladder continues.
- on-ladder TURING_A (0xc597) 3D object allocation before the compute
object (best-effort) to initialize server-side GR-instance state.
- promote mode 24: the reference FWCLIENT non-3D set (MAIN, PM, PATCH,
FECS_EVENT, PRIV_ACCESS_MAP, UNRESTRICTED_PRIV_ACCESS_MAP) as one
GPU_PROMOTE_CTX on the KMD channel, with per-entry logging and explicit
omission semantics; mode clamps/descriptions extended to 24.
Live: mode 23 soft-stops 0x1f on the server-managed shared channel and
reaches the per-buffer commit on the KMD channel, where it stops at the
missing engine-context memdesc; mode 24 emits all six entries and is
refused with 0x1f before BIND. All cycles release clean, GPU green.
|
| |
|
|
| |
The hVirtMemory no-entry promote backed by the server-owned FBMEM context object (GSP_RM_ALLOC class 0x40) on the server-managed shared V5 channel. A physical memdesc bypasses the server-booked engine-ctx vaList and hands the memdesc straight to the per-buffer commit 0x5b00d2c, the one remaining promote shape on the stable shared+srvctx path. Runs grv23/grv23v6 soft-stop at PROMOTE_CTX hVirtMemory status=0x1f before BIND with clean releases.
|
| |
|
|
|
|
|
|
|
| |
Make gsp_phys_rmcall_srv_ctxcommit an int mode: 1 (default) = map +
INITIALIZE_CTX + UVM-shape VA-only promote; 2 = V6 client variant, no
INITIALIZE_CTX and one combined PA+VA MAIN entry with bInitialize=1 and
bNonmapped=0 so the first ctxsw initializes from the golden image; 0 = pure
server-managed. Lets the next supervised cycle bisect both entry shapes
without a rebuild. Build clean; not hardware-tested (GPU wedged).
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Source-confirmed: with the SKIP_CTXBUFFER_ALLOC channel flag the server does
not allocate MAIN, does not map/book it, and its internal init/promote
helpers return early for KMD virtual contexts. The client therefore owns the
buffer. When no server MAIN is reported on a V6 channel, map the prepared
client MAIN at the ladder ctx VA (sysmem PTEs), send GPU_INITIALIZE_CTX to
install the memdesc, then the UVM-shape VA-only promote; with no server
pre-booking the vaListSetManaged gate should pass and the per-buffer commit
program the engine context pointer. V5 keeps the historical PA-only
fallback. Build clean; not hardware-tested (GPU wedged).
|