summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAge
* vgsp-sema: SESSION 127 follow-up - gate the C5C0 translator behind ↵Arthur Hanson Rasmusson17 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 Rasmusson18 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.
* docs/04-real-render-walls: SESSION 126 update - the fence fold landed ↵Arthur Hanson Rasmusson20 hours
| | | | (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
* tools/guest-diag: fenceword_assist.py marked SUPERSEDED (SESSION 126 fence ↵Arthur Hanson Rasmusson20 hours
| | | | fold, 95e7f57e) - the service now authors the Vulkan fence releases itself via the sema_gr_ahead ring-continuation sweep (r717 evidence: sema-ahead h=0xbeec0100 put=11 swept=10 rels=4 -> sema-svc: deferred release va=0x45ba090 payload=1 (was cur=0) x3, VKFRAME seq/DONE with NO assist); keep as A/B fallback for boots without the fold (sema_gr_ahead=0); evidence in backups/evidence-20261002-victory/r717-fencefold/ (gitignored)
* vgsp-sema: SESSION 126 FENCE FOLD - channel-anchored sweep of a GR channel's ↵Arthur Hanson Rasmusson20 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
* tools/guest-diag: fenceword_assist.py - host assist that releases the live ↵open-iov21 hours
| | | | vk_frame120 Vulkan fence wait word (session 125): the fence word is the +0x90 slot of the same 16 KB /dev/nvidiactl BO whose +0x80 slot carries the t122 BW init wait word; the assist finds the BO in the client's rw-s mappings (init word 1, fence word 0) and writes 1 to +0x90 per submit. With it, the t122 client reaches VKFRAME seq=1..3/DONE and writes real PPMs to /tmp/vkout (r715: vk-0001..0003.ppm, content still black - the GR shader work is the next gate, not the fence). This tool is the direct predecessor of the service-side fold: the submit push carries an INC-5 group targeting the same slot (observed [2005c017][0x45ba090][0][payload 1][0][0x02100001]) and the service's translation for that VA is correct (verified against the client pagemap), but the group sits in a push region the decoded entry windows do not cover - next: dump the full 11-entry rings and find/cover that entry.
* vgsp-sema: THE CONSUME-WITHOUT-DECODE BRANCH FIXED - the strict ↵open-iov21 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 Rasmusson22 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 Rasmusson22 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 Rasmusson22 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 Rasmusson22 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 Rasmusson22 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 Rasmusson22 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
* wall2: pdbtick.py loops (retry content-location + trigger every 1 s); ↵Arthur Hanson Rasmusson22 hours
| | | | session 117 evidence: the host-triggered pdb anchoring WORKS end-to-end (sema-pdb-disc -> 'VAS 0xfade0002 page directory registered after verified ring walk (pdb=0x109277000 entries=4 ap=1)'), the small GR pushes decode after the anchor (sema-push: h=0xbeec0100 va=0x4ca096c/0x4ca52c0), but the large ones (976/1432/17316 B) still skip after 210-275 rescues and the fence never releases - next: why the multi-page push reads/plausibility fail for the big pushes (the compute dispatch and the tracker), and give the pump a rewind/replay so already-skipped entries re-decode
* vgsp-sema: host-triggered VAS pdb discovery (sema_pdb_discover va,pa -> ↵Arthur Hanson Rasmusson23 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-sema/wall2: host-triggered VAS pdb discovery (sema_pdb_discover va,pa ↵Arthur Hanson Rasmusson23 hours
| | | | -> verify the parked COPY_SERVER_PDES candidates against a content-verified ring pair, then fall back to the vidmem walk-root sweep) and a runtime-tunable candidate age-out (sema_vas_cand_ms; the default 15 s ages the client's candidate out exactly when its channels first register); tools: fasttick.py (triggers on the GR0 ring resolution line) and pdbtick.py (content-locates the ring page and triggers) - r706/r707 evidence: three parked candidates (0x11cd3d000/0x11cd48000/0x11cd50000 entries=4), the ring pair appears only at channel registration (the same second as the age-out), ring resolution is racy across runs (r706 rc=0 / r707 rc=-2), the skip starts 145-194 rescues (~8-10 s) after the submit; next run: keep candidates parked + trigger within the window
* wall2 session 115: decompose the first-fence wall - the sema service cannot ↵Arthur Hanson Rasmusson23 hours
| | | | decode the submit's GR pushes because the client VAS page directory is undiscoverable (walk_probe: discovered pdb=0x0; the COPY_SERVER_PDES candidate is garbage; the r496f vidmem discovery never runs) and the pushbuffer is noncontiguous; the RAM ring scan gives up after 12 slices before the pushes exist; ring pages ARE content-locatable by their GPFIFO entries and injectable via sema_map_add (fence_assist.py) but the ring pair alone does not unlock the push decode; next = extract the pdb from the guest kernel's RM objects (PDB injection) or scan vidmem with the ring pair as verifier
* wall2 session 114: the COMPR+2MB VidHeap class (attr&0xF000==0x2000, owner ↵Arthur Hanson Rasmusson23 hours
| | | | 0x474C0000) is the last allocation gate - a live attr flip (COMPR_ANY->NONE at the ioctl) lets vkAllocateMemory through and the client runs the whole pipeline to the FIRST vkQueueSubmit, then times out on the FIRST fence (30 s, the new wall); the zero-touch create recipe is BC (eglcore+0xB33D30 marker clears) + BW (eglcore+0xDCEBD9 device wait-word chaser, the missing piece) + the a8clear count gate; the fence release (push-page readability/completion after the submit) is the only remaining gate to VKFRAME
* tools/vk: vk_frame gains an optional 7th arg (tiling: 0=optimal default, ↵Arthur Hanson Rasmusson24 hours
| | | | 1=linear) and a buffer-allocation type-retry loop; wall2: the QEMU-gdbstub kernel-breakpoint script (module VAs insert+patch but never fire - the stub's memory context does not resolve module VAs) and the kcore symbol dumper; session findings: the vkAllocateMemory -2 = the image's internal COMPR 2MB-page 64KB sub-allocation failing NV_ERR_NO_MEMORY after the image data alloc succeeds (both tilings)
* vgsp-rm: FB_GET_INFO_V2 COMPRESSION_SIZE reports a comptag pool ↵Arthur Hanson Rasmusson24 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 Rasmusson25 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 Rasmusson25 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 Rasmusson25 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
* wall2 session 111: FB FULLY disproved (whole-256MB fill_vidmem no flip -> ↵Arthur Hanson Rasmusson26 hours
| | | | memdesc not FB-backed); refined assist negative; SYS-fill of active neighborhoods wedged the guest (cycle next; never bulk-overwrite active-set-adjacent pages)
* wall2 session 110: the sec2 loop runs CONTINUOUSLY inside one long-lived ↵Arthur Hanson Rasmusson26 hours
| | | | ioctl that holds the RM write lock (closes the lock model: tid 1791 read-wait, new clients D-state); the 299-byte reader is a red herring (address never mapped, 5/s); PEBS unavailable; sema-address instruments exhausted short of blind assist
* wall2 session 109: zero-ioctl window vs 24% kernel profile = BURSTY retry ↵Arthur Hanson Rasmusson26 hours
| | | | rounds between 200ms heartbeats; the 299-byte reader named as a health-poll candidate; next = name the node and capture the burst with host-RPC correlation
* wall2 session 108: content-diff found 9 active driver pages (counter/staging ↵Arthur Hanson Rasmusson26 hours
| | | | semantics catalogued); the stuck loop's read is constant -> the sema is a static cell; next = bounded zero-cell sweep among the constant pages adjacent to the active set
* wall2 session 107: FB assist sweeps negative (320+1024 cells; perf still ↵Arthur Hanson Rasmusson26 hours
| | | | 23.13%) - memdesc read not FB-sourced; the byte-identical stream twins (0x1026ad000/0x12afba000) are the memdesc-backing candidates for the next assist sweep
* wall2 session 106: channel buffer is driver-internal (not in ↵Arthur Hanson Rasmusson26 hours
| | | | NV_CHANNEL_ALLOC_PARAMS; kprobe was the right path, notrace-blocked); finish-tail sweep + auth-tag hash scan negative; next = transfer-shadow properties or bounded FB assist
* wall2 session 105: kprobe blocked (channelReadChannelMemdesc is notrace; ↵Arthur Hanson Rasmusson26 hours
| | | | tracefs mounted, UVM kprobes pre-existing); BAR1-path analysis (pokes landed in the shadow yet no flip -> memdesc page != FB 0x660b10); channel-field offsets enumerated; next = CE channel alloc-params dump for the channel-buffer field
* wall2 session 104: sema VA 0x4b19b10 verified NOT the loop page (converged ↵Arthur Hanson Rasmusson26 hours
| | | | FB 0x660b10 pokes landed, no flip; perf still 24.52%); kprobe on channelReadChannelMemdesc names the real authTagBufSemaOffset (offset=%si) + the channel pointer -> memdesc
* wall2 session 103: scrub init stream content-located (pa=0x114e98000 + ↵Arthur Hanson Rasmusson26 hours
| | | | twins); release 0x4b17e30 delivered (cur=1); auth-tag sema 0x4b19b10 page ambiguous (FB 0x660b10 garbage did not flip; linear guesses zero); next = validate-by-value walk pick
* wall2 session 102: fd sampler found no transient (bursty reader); no nvidia ↵Arthur Hanson Rasmusson26 hours
| | | | debugfs; memdesc paths ranked (content-locate the channel buffer by scrub method shapes / scrubber sema-push decodes / narrower burst sampling)
* wall2 session 101: auth-tag wait loop decoded (sema at ↵Arthur Hanson Rasmusson26 hours
| | | | pChannelBufferMemdesc+finishPayloadOffset+4, exits when GetPtr passes nextPut); perf trace (no-ptrace) shows the 10ms futex retry + a transient open/read(299)/close polling reader; next = catch the transient fd path and write the sema
* wall2 session 100: CE userd hunt exhausted standard layouts (registered ↵Arthur Hanson Rasmusson26 hours
| | | | FB=zero, ring+0x10000 non-contiguous guesses=zero, PDB-walked gpfifo+0x10000 pages=all-zero); the SEC2 scrub flow is a circular wait (no consumption without the CE pump; no pump without a live userd; no userd without submits); next = write the auth-tag sema in the channel buffer (memdesc) page directly to free the slots
* wall2 session 99: scrubber gate connected to CE channels ok=0 (userd ↵Arthur Hanson Rasmusson26 hours
| | | | discovery fails for all CE-class channels; GR ok=1 and pumping); find_userd FB scan = zero; host shape scan too noisy; next = diff-watch to pinpoint the real CE userd page
* wall2 session 98: post-device spin NAMED via perf (no ptrace) - the SEC2 ↵Arthur Hanson Rasmusson26 hours
| | | | memory-scrubber channel waits on its auth-tag semaphore (channelReadChannelMemdesc 24.33%, _sec2utilsGetNextAuthTagSlot loop); fix direction = service-side completion of the scrubber's semaphore releases (authTagBufSemaOffset in the channel buffer); perf is the new no-ptrace spin locator
* wall2 session 97: deep submission state reached (gpfifo done=11576, ↵Arthur Hanson Rasmusson26 hours
| | | | pushes=10932); counter-slot collision (stale owner) + sema_counter bypass applied (pub_calls 1356->3739); post-device spin is the remaining gate; ioctl-arg sampling axis documented
* wall2 session 96: detach-first clearer t106 PROVEN (BC-DETACHED, TracerPid ↵Arthur Hanson Rasmusson27 hours
| | | | 0, VKDEVICE via 5 words on r696); orphan-tracer plague root-caused (interrupted gdb attempts) with strict discipline; next t107 = clearer+diagnostic in one self-contained gdb window
* wall2 session 95: gdb thread-stop interference freezes clients (workers ↵Arthur Hanson Rasmusson27 hours
| | | | stuck in ptrace_stop); SIGKILL nuance (tracees resumed when stopped at futex, survived); RM-lock holder dynamics; harness rules + service-side folding as the durable answer
* wall2 session 94: instance clears proven REQUIRED (zero-gdb run still -4'd); ↵Arthur Hanson Rasmusson27 hours
| | | | t104 self-exiting clearer + unwait reaches VKDEVICE again; next: detach-from-handler t104 so no gdb is ever held + t102 wait identification
* wall2 session 93: zero-ptrace pipeline (t101 instance clears self-disabling ↵Arthur Hanson Rasmusson27 hours
| | | | + unwait.py 16K/+0x80 word poller) reaches VKDEVICE on r693 with 5 auto-written words and no wedge risk; RM-lock wedge root-caused (gdb killed at a stop inside an RM critical section) with new attach rules + t102 safe diagnostic
* wall2 session 92: automated zero-touch pipeline reaches VKDEVICE on a fresh ↵Arthur Hanson Rasmusson28 hours
| | | | boot (t99 = marker-clear at +0xB33D30 + wait-word chase/write at +0xDCEBD9); live_walk PT injections alongside; attach-discipline lesson (wedged continue blocks later attaches); next = post-device wait identification
* wall2 session 91: vkCreateInstance wall BREACHED - the event-slot ↵Arthur Hanson Rasmusson28 hours
| | | | pending-marker (u16@+0xe=0xffff) cleared at each +0xB33D30 retry entry passes the instance phase for the first time; client then persists in vkCreateDevice's nvidia0 poll waiting for the event-fd signal (guest dispatch gap); tools t93/t94/t96b/t97
* wall2 session 90: current-boot wait site identified (eglcore+0xB2852D ↵Arthur Hanson Rasmusson29 hours
| | | | in-process word pair wait inside vkCreateInstance; old 0xa85d24/16K sites dead this boot); t83 sampler + widened nudge tools; multi-word nudge trips -4 (caution confirmed)
* wall2 session 89: counter-page record resolve proven live (slot learn + ↵Arthur Hanson Rasmusson29 hours
| | | | pub_calls 0->172); GR ctx-init release apply remains the single unmet wait
* wall2 session 89: GMMU PT walk replicated host-side + live inject ↵Arthur Hanson Rasmusson29 hours
| | | | (validated: ring entries and push method streams match); gpfifo done 0->6; root cause of -4 = release-apply gates (gr_forward defer-arm, op_tr_pending opdef withholding) + unresolvable counter page 0x20400f000 (slot stays pending); counter-page {pa,va} record tables found for host-side resolve (live only)
* wall2: session 88 - push page-5 injection fix (proven +30/sweep), ↵Arthur Hanson Rasmusson30 hours
| | | | host_resolve tool, RING GAP diagnosis (gpfifo done=0), gdb-SIGKILL RM-lock wedge lesson
* wall-2 session-87: window page-list hunt - the 2 GiB cycle's windows are ↵Arthur Hanson Rasmusson30 hours
| | | | scattered (later offsets at first_PA+off are zeros); the memdesc {size 0x20000, PA=0x107c47000, kptrs} page list is only reachable via the kernel pointers (kcore walk with fresh addresses needed); content search for the init-stream prefix found the window pages (0x103c06000+0x858, 0x11dbfa000+0x858, 0x126d69000+0x59c) but the VA<->page relation is non-linear; the client blocks in os_schedule at the allocation (the unread later pushes suspected)
* wall-2 session-86 tools: vk_memprops.py (standalone Vulkan memory-properties ↵Arthur Hanson Rasmusson30 hours
| | | | dump), vk_alloc_test.py (standalone allocation reproducer), t91.py (auto-clear + ICD memprops/alloc hooks), t90.py (A8 count auto-clear)
generated by cgit v1.2.3 (git 2.39.1) at 2026-10-26 20:26:59 +0000