| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
| |
first-submission capture caused the CUDA stall regression (fixed, a674c21c); the Vulkan CE rings live at 0x4020000/0x4100000/0x4160000 (above the 64 MB capture bound) and the frame chain reduces to the un-latched ring (copy pend -> dstpend -> black)
Records the instrument, the regression A/B (r746-era module passes, SESSION
133/134 code spins), the rank-aware fix and its r781 verification, the
Vulkan client's actual ring allocations from its own vidheap ioctl log, the
failed 4 GB RAM entry search, and the live frame dependency (GR launch
inline=8 + copy pend src 0xdff0d60000 -> vidmem 0x570000, dst framebuffer
0x50b0000) with ranked next steps.
|
| |
|
|
| |
is FOUND (the driver embeds the program bytes INLINE in a CE LAUNCH_DMA push: in=0x120a00004 -> out=0x205000, 4096 B/run; the Vulkan CE channels carry the same-shaped entries) and the three gates that keep the copies from running are named: the CE ring/USERD boot-lottery (FB convention matched r763 only; the real USERDs sit at 0xfee00/0xff000/0xff200 so the rings are at unaligned offsets like 0xefe00), the VAS age-out vs CE grace race (sema_vas_cand_ms=5000 registers at +5s), and the volatile ring/USERD content that a periodic shadow scan misses; next steps: USERD-shape-derived ring resolution or first-submission latch, then the inline copies and the n_data wiring
|
| |
|
|
| |
PROVEN in guest RAM (walk-confirmed per-run pages 0x11623d000/0x104b55000 with the 14-entry content the sweep decodes; the vidmem 0xa0000 'ring' was a false-positive autopin whose entry0 push reads all-zero and which the pump skipped after 39 rescues); the fixes (dead-entry guard + cross-aperture USERD + per-client util witnesses + op-level copyent) and their verification (r760: ring rc=0 on the live RAM page, live entry reads, VKFRAME_DONE 3 frames); the two LID uploads are the driver's zero buffers by design (256 B zero buffer + 12288 B CE fault buffer) while the GR channel's LID carries the real param bank; the code VA (prog=0xdfd8feb900) maps to a ROTATING code pool (0x62b900 -> 0xc8b000) whose lat entry can go stale and whose pages are empty - the SASS delivery shape (C5C0 0x3800/0x39C8 runs) and the walk-first code-VA resolution are the next two gates
|
| |
|
|
| |
frontier: the CUDA client's uploads fill the emulated vidmem (~450k non-zero dwords across many 1MB blocks) while the Vulkan client's leave only the 14 baseline dwords, so the Vulkan (NVN/GL) upload path is not among the writes the emulation can see; next steps recorded
|
| |
|
|
| |
in vidmem (map PA 0xa0000, live entry 0x120100000/40) and the decoded 14-entry LID ring is a STALE page from a dead session, which is why its payload chunks read zero through every path (four reads + BO poller + gdb write-watchpoint); the CUDA contrast proves the LID arm works with real contiguous payloads; next step is reading the live ring through the map and decoding its entries
|
| |
|
|
| |
LOAD_INLINE_DATA arm fires (branch-order fix), the payloads are the driver's zero buffer (four-read proof + full-run BO poller + gdb write-watchpoint), the SASS delivery is the remaining non-black gate (prog page 0x62b000 empty; NVN download path targets the pitch-pool allocation), plus the xlate/util_scan regression bisect result
|
| |
|
|
| |
(sema_gr_ahead sweeps the pre-built GPFIFO continuation beyond GP_PUT and applies the submit pushes' INC-5 RELEASE groups forward-only through the pending ledger; VKFRAME seq/DONE with no host assist) and the compute-dispatch shape decoded: a direct C5C0 method stream (SET_OBJECT + 0x7b4/0x2a4/0x270 windows + 0x3800/0x39C8 code runs + a subchannel-0 data-port stream), NO inline-QMD write, so the existing launch capture/physical forward never fires - the translator that builds the vendor launch from the C5C0 section is the execution gate
|
| |
|
|
| |
(rmapiAllocWithSecInfo enters with class 0xc57e, serverAllocResourceUnderLock returns 0x56 before the GSP-RM RPC at under-lock+0x447; _rpcAllocObjectPrologue exonerated); the guest's not-stripped nvidia.ko is a new live-debug instrument; gdb-stub hazards recorded (kill wedges the VM - detach-only recovery; stepi loops wedge the guest - prefer conditional breakpoints)
|
| |
|
|
| |
ALLOC_DEVICE reply status 5 (CORE_CHANNEL_ALLOC_FAILED) decoded by the LD_PRELOAD nvKms logger with a widened reply scan; the empty display capability notifier is the first missing piece (a live-gdb fill of SYS_CAP/SYS_CAPB flips the driver to the window path, proving numWindows>0 unblocks it); the residual wall is the vGPU-guest display-class rejection: nvRmApiAlloc(0xc57e) returns NV_ERR_NOT_SUPPORTED inside the guest kernel and never reaches the emulated GSP - the guest runs in vGPU mode where display/modeset classes are host-service-provided by design
|
|
|
enumerates on the emulated vGPU; vkCreateDevice fails in nvidia-modeset's ALLOC_DEVICE past the new NV0073 head/connector shim, residual wall = the display core/modeset channel objects; Xorg ScreenInit fails in nvidia-push's 10 s channel test with submissions=0 and unresolved X-channel VAs - the guest scanner serves CUDA clients only - plus a rank-0 counter-slot collision with a live CUDA client; EGL/glsi unchanged) and link the page from the README
|
