| Commit message (Collapse) | Author | Age |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
clear_trace() on a pid switch dropped exactly the one-shot uvmt/uvch
events of the new client when they landed in the switch instant; the
pipe reader then never saw them and the whole session ran with an empty
sem set (r126: vecadd_loop sem=0 for minutes while its CE entries paid
the 8 s grace). Scan the ring tail once per switch and seed the sets
instead - stale kptrs that are also re-learned resolve to no content and
are deferred by the candidate scoring.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The kptr-keyed one-shot latches assumed object identity, but UVM frees and
re-creates CE push-buffer rm_mems and channels mid-session and the slab
reuses the same addresses; a resolution taken before such a move pinned
pages that read all-zero when the host used them, so every CE ring entry
stalled in the 8 s grace (r125: the live pushes sat at new vmap pages of
the same rm_mem kptr). Candidates are now scored by their window content
(a live push buffer is full of method streams, a freed range reads zeros)
and the best is pinned - all-zero candidate sets emit nothing instead of
poisoning the host map. A resolved mem is re-validated every ~2 s against
its own {cpu,gpu} fields and first-page PA; when they move, the latches
drop and the current truth is re-emitted.
|
| |
|
|
|
|
|
|
|
| |
The pump works on a snapshot copy of the channel table; without the
end-of-pass write-back the hold window was re-armed every pass and a
launch whose argument pointers never translate was never consumed (r122:
smiley's launch held forever). Persist gr_hold_until/gr_hold_idx so the
hold is exactly one bounded window per entry, then the entry is consumed
as before.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
derive the CE vmap pairing per allocation
Two second-client zeros/stall countermeasures:
- svc_gr_data_fill now reports when a launch carries high (device-space)
argument pointers and none of them resolves through any trusted source.
svc_gr_request refuses to forward such a launch and leaves the capture
unconsumed; the pump holds the ring entry for one bounded window per
entry (gsp_sema_gr_grace_ms) and retries it, so a translation that
appears a pass later (scanner pin, published directory, learned pair)
is used instead of executing the kernel against unresolved pointers.
On window expiry the entry is consumed exactly as before (bounded
zeros, never a hang). Bounded per-session fill diagnostics name the
source that serves each candidate (ipin/pin/lat/map/vas/disc/win) and
dump the published vaspace walk results for misses.
- The CE push-buffer kcore chain resolver derives its vmap page offset
per allocation instead of using a fixed shift: the rm_mem size is read
from its real offset (570.144 layout) and paired with the vmallocinfo
area page count, so a leading header page is only skipped when it
actually exists. With an unreadable size the two candidate offsets are
content-probed with the host's method-stream plausibility test and an
ambiguous result keeps the status-quo pairing. This removes the
off-by-one that fed wrong push pages to the pump (content-rescue
crawl).
|
| |
|
|
|
|
|
|
|
|
|
| |
The +1 vmap pairing was content-validated on one boot's CE push-buffer
allocation (4097-page vmap: five rescue anchors at k+1), but r116/r117
show the leading header page is not universal: with the shift applied
client #1 stalls mid-run (rescues resume) where it was green without it.
Reverting the shift restores the previous behaviour; the kernel-side
repair from 16124929 stays (a content-validated rescue replaces the
injected pair, so a wrong pin is corrected once per page instead of
being re-rescued on every pass).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
rescues repair injections
The CE push-buffer uvm_rm_mem is vmalloc'd as a 4097-page area: one
leading page plus the 4096-page (16 MB) GPU data window, so GPU data
page k lives at vmap page k+1. The kcore chain resolver paired page k
with vmap page k, pinning the adjacent push for every page; the pump
then read the wrong push, decode failed, and the host fell into the
content rescue which crawled one entry per ~2 s (r115: rescue_run=4202,
entry_va=0x12001b18c repeating). Verified against five independent
content-validated rescue anchors (k=20..28, all delta +1), and the vmap
area boundary confirms the extra page (nv_vm_map_pages 4097 pages).
Five fixes:
- resolve_mem_pins() takes page_off; the CE chain and uvbp push-buffer
paths pass mem_page_off() (1 when the vmap is exactly 16 MB + 1 page;
0 for direct-mapped mems like the semaphore pool).
- a content-validated rescue page now also replaces the injected-pin
entry (svc_rescue_try / svc_rescue_run_try), so a stale or wrong
injection can no longer shadow the validated page and re-run the
rescue on every pass.
Evidence: r115 rescue anchors va 0x120014000->pa 0x12a2e2000 .. va
0x12001c000->pa 0x12a2de000 all at vmap offset k+1; the candidate pages
decode as the adjacent push (wrong semaphore payload) before the fix.
|
| |
|
|
|
|
|
|
|
|
|
| |
Two robustness fixes for the sequential client battery. cdt_pid() now
picks the highest-pid CUDA candidate: preferring a name-prefix match
kept the scanner pinned to a previous client that was still tearing
down while the new client had already started pushing, so its first
pushes were unreadable, the release expectation drifted past the real
payloads and the stall followed. The CE push-buffer chain resolver now
also runs for uvch channel kptrs, so the pins do not depend on the uvmt
semaphore events alone.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
stall)
The second CUDA client's GPFIFO entries in the CE push-buffer window
(0x120000000) had no injected pin: that window is never mapped into the
client's pagemap, so the scanner's window scan cannot see it, and its
only supplier - the one-shot uvbp kprobe event - is raced by two trace
clears (the scanner's pid-switch clear and semfix's trace-tail clear).
When the event loses the race the entry reads fall back to the ~250 ms
content rescue, which is the second-client stall and the same
resolution-miss class as the ISSUE-0001 lottery.
The guest scanner now walks channel->pool->manager->pushbuffer->rm_mem
in kernel memory with kcore and pins the push-buffer pages directly (no
trace event to lose), and the trace reader's dedup marks reset on a
client switch so a reused kptr cannot suppress the new client's #pb.
Boot evidence (r112): rescue reject ipin=0 for va_page=0x120023000,
rescue scans 175 ms - 1 s each, want incrementing to 39. Smoke test of
this fix on the stalled VM: 478 pin runs (~7955 pages) streamed within
seconds, first va=0x120000000 -> pa=0x108090000. A bounded kernel log
now prints the first CE push-buffer pins of each session.
|
| |
|
|
|
|
|
|
|
|
|
| |
(second-client zeros)
The watcher's pins for the second client's a/b/c buffers can land between
the service loop's svc_handle_map_add() and the launch capture; the fill
then misses them via svc_ipin_lookup, resolves 0 pages, relocates nothing,
and the win0 param page keeps the driver's guest VAs (rk1: candidate[0..2]
-> 0 new pages; DIAG win0[0] 160=753e4ec00000). Drain the queue right
before svc_gr_req_fill() (same service thread, no race).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
registration; scanner streams anonymous high-VA buffers
Second-client wedge fix: a new GSP session re-registers the same channel
handles/ranks, but the per-rank one-shot ring/push-buffer discovery latches
stayed set from the previous session, so the new session's ring was never
re-autopinned (ring_auto=0 pb=0/0, nomap growing) and the guest spun in its
channel-creation wait. svc_chan_rearm_rank() clears the latches on every
channel registration; all post-fix cycles launch the second client.
Scanner: guest_pin_stream.py now streams the client's anonymous high-VA
mappings (cudaMalloc buffers were skipped by the old len(parts)<6 check),
so the host can learn their pages.
Diagnostics: PT-window lines, per-window first words, post-OK qmdwin
w48..59. Remaining: the fill-time svc_ipin_lookup miss for the second
client's a/b/c pins (they exist in the pin log but are not seen at fill
time) - next session.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
(second-client fix)
r99/r100: the fresh session's reused pool page reads the previous session's
residue (cur=2) before the first genuine release (pay=1) is translated; the
translated read set ch->pool_rel_seen, so every later residue release
(payload <= cur) was silently dropped by the final else and the client spun
at DEVICE forever. A read that applied or deferred nothing now leaves the
flag clear so the r63/r64 residue re-seed still fires for the first genuine
release of the session.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(second-client fix)
Second-client launches scanned a stale/reused guest param page that still
held the FIRST client's device VAs: zero new candidates resolved, nothing
was relocated, and the engine executed with unrelocated guest pointers
(r97 evidence: client#1 '15 candidate ptrs, 100 pages resolved' and win0
param 160=110400; client#2 '12 candidates, 1 page' with 160=75552ec00000
unrelocated). The driver-authored inline param block is captured from the
pushbuffer at request time, so scanning it makes pointer discovery
independent of guest-page reuse timing. Adds svc_gr_scan_cand()/
svc_gr_scan_inline() and the DIAG win0/guest-param proof line. Client #1
stays green (4 cycles); the remaining second-client stall is the pool
semaphore residue (see next commit).
|
| |
|
|
|
|
|
|
|
| |
- titles.json: map relative doc links to https://git.vgpu.io/open-iov.git/tree/...
(the host runs cgit; /blob/ URLs do not exist)
- check_site.py: verify every git.vgpu.io URL on every page resolves (HTTP
status check, cached, with backoff)
- site pages: repository home links point at the .git/ URL
- .publish-manifest.json: revised revision records
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
- tools/site: Markdown-to-MediaWiki converter (tracked-paths-only link
mapping, local-marker scan, About-message insert), WikiBot publisher
with diff/check modes and publish manifest, live site auditor, image
uploader, site-only page sources (landing page, About, index, sidebar,
banner templates, About-message template).
- wiki: new public deep-dive sources (project status, install, FAQ,
system overview, GSP and GSP-RM, execution frontier, host module,
guest stack, UVM, physical backend, driver lifecycle, risc-v-gsp-rm-debugger,
hardware/software matrix, HAAEEP, glossary); refreshed CUDA userspace
status; corrected cross-document links; README rewritten for the new set.
- wiki/.publish-manifest.json records each published revision for rollback.
|
| |
|
|
|
|
|
| |
default
smiley (cudaMallocManaged-class, known-failing until the param-offset
fix) moved last so a baseline pass exercises the other 13 first.
|
| |
|
|
|
|
|
|
| |
victory_saxpy, victory_reduce (shared+atomics), victory_matmul (tiled
shared), victory_strided, victory_memset2d (pitched), victory_atomics,
victory_streams_events (3 streams + events), victory_math (mixed
int/float/double). Each verifies via readback and prints STATUS OK|FAIL.
soak.sh now runs the full 14-client set (seq or sustained).
|
| |
|
|
|
| |
Discriminates engine-side writes of float data (kernel ran with c on this
buffer) from non-kernel writes (pointers/QMD-shaped words).
|
| |
|
|
|
|
|
| |
8 changed pages x 4 passes for smiley vs 33 for victory's vadd - the
indexes name the relocated range (bi >= 0x40 = the c-pointer output
window 0x150000+) and discriminate engine-side partial dispatch from a
guest write-back/read attribution failure.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
save/unload lottery)
r90 evidence: the 3rd session's forwarded launch entered SKED (CWD VALID)
and was then saved/unloaded by the FECS before dispatch; qmd_rel stayed at
5/6, GP_GET froze, and every later launch on the boot was never fetched
either. The service owns no repair path, so the channel stayed dead until
reboot.
On the first poll timeout, re-issue the two GPFIFO_SCHEDULE controls the
stage-4 sequence used (channel-level 0xa06f0103 + TSG-level 0xa06c0101,
both proven accepted) and re-ring the work-submit doorbell, then poll one
more full window before the postmortem. No BIND, no PROMOTE (m76-m81
proved the explicit PREEMPT/tail variants stop the QMD enqueuing).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ipin-first data resolution
Two fixes and one diagnostic for the all-zero-results class (r89: smiley's
4 vadd launches reported GUEST GR LAUNCH OK yet every output word read 0):
- gsp_phys_booter: copy the guest data pages into the bounce window BEFORE
gsp_phys_rmcall_publish_locked() rings the doorbell. The fill used to run
after the kick; the engine front end starts within ~7 ms, so the kernel
could read the window before it was filled.
- gsp_phys_booter: per-page checksums at copy-in, compared at copy-out;
the copy-out log now reports 'N changed by engine'. An all-unchanged
window after a reported completion is the front-end-ran/grid-never-
dispatched signature (completion semaphores are front-end authored).
The first 3 data (va,hpa,reloc) triples are logged per launch.
- gsp_sema_service: svc_gr_data_fill resolves data pages through
svc_ipin_lookup() first (guest-truth pins), falling back to
svc_resolve_va, mirroring the pool resolver order; a wrong page here
silently runs the kernel on zeros. First 16 resolved (va,pa,ap) triples
are logged for post-mortem comparison against the guest's own mapping.
|
| |
|
|
|
|
|
|
|
|
|
| |
failure)
The watcher's resolve_sem_pool read sem->page->mem->vas through a
process-lifetime cache: a transient zero captured while UVM was still
initialising the structures was served forever, the pool pin never
landed, and the second-session client hung in cudaMallocManaged
(r88 evidence: 'pool unresolved (retry)' from the watcher while the
same walk succeeded from a fresh QMP client). Cache is now opt-in.
|
| |
|
|
|
|
|
|
|
| |
Two failure modes found when the scanner detects clients by device fd:
a transient boot nvidia-smi was picked and its exited pagemap read back
EOF, and scan_window advanced by got=0 forever (busy spin, no stream);
and non-client nvidia fd holders must never be committed to. Break on
got<=0 in scan_window (scan_range already did), skip nvidia-smi/
persistenced/Xorg, and prefer /dev/nvidia-uvm holders.
|
| |
|
|
|
|
|
|
|
|
| |
The guest pin scanner only tracked processes whose comm matched
CLIENT_PREFIXES (cdt,va,victory). An arbitrary CUDA binary (e.g.
/tmp/smiley) was invisible: no pages streamed, no VA->PA pins injected,
the service could not read its pushes and the client hung in
cudaMalloc/uvm_tracker_wait. Detect compute clients by the CUDA device
they hold open (/dev/nvidia-uvm preferred, then any /dev/nvidia*), with
the prefix match kept as the first-choice path.
|
| |
|
|
|
|
|
|
| |
Password auth with key auth disabled outright: the host's id_rsa is
passphrase-protected and a stale copy of its public key in the guest's
authorized_keys made plain ssh hang on the passphrase prompt (the
reported 'sshpass hangs'). Wrapper defaults to 127.0.0.1:2222
ubuntu/ubuntu, overridable via VGPU_GUEST_*.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The launch line carried both an explicit rtl8139 on netdev net0 and a
stray '-net user,hostfwd=tcp::2222-:22 -net nic' pair, creating a SECOND
slirp network with a second NIC and a second 2222 forward. The SSH
connection landed on one slirp instance while the guest's replies left
through the other interface, stalling the handshake before auth. The
explicit rtl8139 now owns the only user netdev with the 2222 forward.
The generated launch_qemu_rootport.run.sh is patched in place by the
harness from the same line.
Verified: sshpass -p ubuntu ssh -p 2222 ubuntu@127.0.0.1 -> nvidia-smi
green. Guest-side companion fix (persisted in the qcow2 image): the
cloud image's /etc/ssh/sshd_config.d/60-cloudimg-settings.conf set
PasswordAuthentication no; it is now yes.
|
| |
|
|
| |
This reverts commit f5961087aa17111c6cdb7f6641626c0c877eee6b.
|
| |
|
|
|
|
| |
(ISSUE-0002)"
This reverts commit 32a9123b087c67c2a8126c6e9789ce36f7371045.
|
| |
|
|
|
|
| |
closing (ISSUE-0002)"
This reverts commit b839a12de675818f41a8cb388e5663d804c2a1f7.
|
| |
|
|
|
|
| |
payload from GP_PUT (ISSUE-0002)"
This reverts commit cf560b257eac2394da84825f12ba0e4192dc74db.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GP_PUT (ISSUE-0002)
The CeUtils scrubber channel (entries=4096, GPU-global) stays registered
across client sessions now that deletion is client-scoped, but its channel
buffer memory is reused by later clients' push buffers: entry-pumping its
stale ring invented work and perturbed the session (r79/r80: the first
client wedged on an rwsem). The pump now skips channels with the
scrubber layout (entries >= 4096) and instead publishes the word the pma
scrub actually waits on - the channel buffer finish payload at
gpfifo_va + 8*entries + 4 (live-verified: 0x120064000 + 0x8000 + 4 =
0x12006c004, the address from the hung client's register dump) -
forward-only from the channel's own GP_PUT (one payload per submitted
push, the same counter the guest's ceutilsUpdateProgress polls).
Skipping the scrub's actual memset work is acceptable for the emulated
vidmem: the guest's scrub clears pages of its own shadow, and the
emulation's job here is the completion contract. Revisit if per-tenant
vidmem scrubbing is required.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(ISSUE-0002)
r79 regression from keeping the CeUtils scrubber channel registered
(client-scoped deletion): the session flush trigger required EVERY
channel to close, and the scrubber never closes, so the per-session
discovery reset never ran and the next client inherited the previous
session's map/pins (the r9 class; the first client of r79 wedged the
guest on an rwsem with no output).
The session is now keyed by owning client: channel_add records
svc_sess_client and requests the flush when a channel of a DIFFERENT
client registers while the previous session is live (then waits for it,
exactly like a pending flush); channel_del's flush trigger counts only
channels of the current session client, so persistent kernel/GPU-global
channels (the scrubber) no longer keep a dead session open.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
r78 validation of the client-scoped deletion: the boot session's CeUtils
scrubber channel (client != the UVM client, entries=4096) stayed
registered as intended, but it consumed CE rank 0 and every UVM channel's
rank shifted by one. Ring autopin and push-buffer pairing derive the ring
and pool-semaphore offsets from the rank (0x121010000 + 0x30000*rank,
0x121000000 + 4*rank), so the first client's pairing went to the wrong
offsets and the guest wedged on an rwsem (sysrq: rwsem_spin_on_owner).
Rank is now counted only among live channels of the same owning client;
the UVM client's channels keep ranks 0..5 and the kernel/GPU-global
scrubber gets its own (unused for the pool layout) rank. Missing clients
keep the old counting.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Handles are per-client, but the FREE path unregistered any channel whose
numeric handle matched the freed object, with no client check. r77 root
cause of the third-client pma scrub hang: the boot session's CeUtils
scrubber channel (h=0x2, gpfifo=0x120064000, entries=4096) was
unregistered when an unrelated class-0x2080 object with handle 0x2 in
client 0xc1d00011 was freed. The guest kept using the live channel for
the scrub; the service no longer pumped it, its pushes were never
decoded and the channel-buffer finish payload (pbGpuVA+0x6c004) was
never written, so scrubCheckAndWaitForSize polled forever (sysrq stack:
ceutilsUpdateProgress -> channelReadChannelMemdesc).
Channel registration now records h_client (the RM alloc header's client)
and deletion matches (h_object, h_client); a missing client on either
side keeps the handle-only behaviour. Re-registration keeps the
counter/release slots only for the same (handle, client) pair. Live
proof from the hung VM: sema_probe translates the finish-payload VA
0x12006c004 to pa=0x10f962004 aperture=ram - the word the guest polls is
reachable; the channel was simply invisible to the pump.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
BAR1 aperture (ISSUE-0002)
The pma scrub in a second/third CUDA session memsets a legitimate vidmem
offset at 262M (inside the 512M turing shadow) and the copy path rejected it
with -EINVAL because every FB bounds check compared against
vgpu->bars[1].size, the physical BAR1 aperture exposed to the guest (256M on
TU104). The op was held and retried forever (opdef), the GR scrub waited in
scrubCheckAndWaitForSize and the client froze.
All bounds checks that guard a dereference of the emulated vidmem shadow at
vgpu->bars[1].vaddr now use nv_vgpu_fb_emul_size() via svc_fb_shadow_size():
the copy/fill paths, svc_read_ap/svc_write_ap, svc_ap_ok, the page-directory
discovery scans, svc_lookup's vidmem VA translation, the GRCE inline write,
svc_fwd_operand_hpa and the debug scans. The 2 MB leaf path of svc_gmmu_walk
now validates through svc_ap_ok like every other leaf path so an
out-of-shadow translation falls through to the shadow fallback instead of
reaching the copy path. The RM page-directory debug peek is bounded the same
way.
Evidence: r75b live log: sema-bigcopy dst_va=0x76aa08e02200 -> pa=0x10602200
ap=0 prov=3; sema-bigop rc=-22 repeated; guest sysrq stack
scrubCheckAndWaitForSize -> pmaAllocatePages.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
r73 c3 rank2: discovery read the previous session's residual put (67); the
pump consumed the live entries 0..1, the r48 resync handled the first drop,
but the guest's counter then settled at put=1 while last_get=2 and
userd_wait_fresh was already consumed. The loop condition last_get != put
then marched ~1023 slots the producer had not written, holding each stale
entry for the full CE grace (one fake release per 8 s) - the client looked
wedged and the exec timed out.
When a drop leaves the pump ahead of the producer on a channel with fewer
than half a ring of submissions, rewind last_get to put instead of marching.
A genuine ring wrap needs a full ring of submissions, so this cannot skip a
live entry.
|
| |
|
|
|
|
|
|
|
| |
r72 showed the broad rule holding entries on small failed ops too: two
opdef holds on h=0x5c000059 (entries 82/84) were never resolved and withheld
their releases for the whole session, while c2 hit the pre-existing GR launch
forward timeout. The scrub class this rule exists for is always large (r58/
r71: 1 MiB / 297 KiB / 608 KiB), so only failures of ops >= 256 KB mark the
pass op-pending; small failing ops keep the old consume-and-apply behaviour.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(ISSUE-0002)
r71 c3 reached the pma scrub and froze in scrubCheckAndWaitForSize: three
vidmem memsets (1 MiB / 297 KiB / 608 KiB) failed with -EINVAL because
svc_op_translate resolved their client-VA destinations through a walk to an
out-of-bounds vidmem translation before the scanner pinned the real sysmem
pages. Only svc_op_translate's own failure sets op_tr_pending, so the pump
consumed the entry and applied the release while the memset work was lost.
svc_run_ops now marks the pass op-pending for any op that did not run
(rc != 0, rc != SVC_COPY_FORWARDED): the pump holds the entry and withholds
its releases (bounded by SVC_OPDEF_HOLD_MS) so the retried decode picks up
the injected pin and runs the memset; on expiry the release is flushed and
the op stays skipped, exactly like the -ENOENT path. Sessions with no failed
ops (c1/c2 were 0 fails in r71) are unaffected.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
submissions (ISSUE-0002)
r70 c3 proved the submissions gate wrong: the content-rescue path consumes
entry 0 (submissions++) while the pool page is still untranslated (rrc=-2),
then the scanner's pin batch rewinds last_get (SVC_PIN_REWIND) and the entry
is decoded again - this time with cur=134 residue, pay=1, but submissions
already 1, so the residue branch was skipped, the hold branch deferred the
release, and the pending retry dropped it (payload <= cur). The client's
first tracker wait then never completed.
Replace the freshness gate with a per-channel pool_rel_seen flag set on the
first translated pool read (rrc2 == 0), persisted in the pump write-back. The
residue rule now fires exactly on that first read, exactly once per channel
per session.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the pool word is residue (ISSUE-0002)
A fresh session's first CE release could read a previous session's value
through the just-injected pool pin (r64: cur=134 pay=1; r63: cur=114696).
svc_init_expected_payload seeded the channel expectation from that residue,
the release candidate then skipped as stale (payload <= cur) and the client's
first tracker wait never completed.
When the first GPFIFO entry of a fresh CE channel (submissions == 0) decodes a
pool release whose word reads ahead of the payload, treat the word as residue:
re-seed expected_sem_payload/entry_want from the payload and apply the release
absolute instead of skipping. Monotonic trackers make the absolute write
idempotent; displaced pins stay owned by the fan-out/pending paths. Bounded
'sema-chan: pool residue' diagnostic plus a residue counter in the drain line.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
r65 showed the operand-hold release gate must not run before the
forwarding gate: for a GR launch push whose software operand was
pending, the operand hold applied the launch-completion release as soon
as the software op ran, so the client passed the launch-completion wait
while the physical launch was still in flight; when the physical launch
later timed out (qmd_rel stuck at 5, want 6) the client read zeros
(MAIL bad).
Order the release sites fwd-first: when a forwarding candidate is
captured, drop any operand-hold record for the entry (the fwd record set
carries the same release) and record into the fwd set so the hardware
completion (or its bounded fallback) is the single delivery edge. The
operand hold keeps owning the release only when no candidate is
captured, exactly as r62 intended.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(ISSUE-0002)
The guest's pma scrub submits vidmem memsets whose operand translations
(client buffer VAs pinned by the scanner) land about a second after the
push. r58 lost those ops to the one-pass skip; r59 showed that retrying
them without deferring the entry's releases corrupts the next client
(the late re-run memset executes after the client passed the release and
refilled the staging buffer).
Hold the entry AND record its decoded releases in per-(device, channel,
entry) slots while any op of the pass is untranslated; apply the recorded
set when the retried decode completes every op, deliver it late on entry
consume, or flush it when the bounded hold (10 s, inside the 25 s CE
grace) expires with the op left skipped as before. Slots are dropped on
session flush and for vanished channels. New opdef=held/applied/expired
counters in the drain line.
|
| |
|
|
|
|
| |
mid-scan (ISSUE-0002)"
This reverts commit 0f814465b3af0f75e5203688bba6c04714a78778.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
(ISSUE-0002)
The guest driver's pma scrub submits vidmem memsets on a GR channel; the
operand translations (client buffer VAs, pinned by the scanner) land about
a second after the push. The one-pass skip lost those memsets forever and
the guest spun in scrubCheckAndWaitForSize (r58 c3: three bigop memsets
rc=-22 at 17:54:35, their pins logged at 17:54:36, the channel froze at
get=89 with the client in pmaAllocatePages). Mark the operand path pending
on any unresolved operand so the existing bounded entry hold retries the
decode until the translation lands; raise the retry bound to 160 so the
hold covers the observed pin latency.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A fresh CE channel can legitimately reach the service's first pass with a
live put far above 1: the driver publishes the put once per submitted push
((cpu_put + 1) % entries) and clients stream pushes while the service is
still discovering the channel. r56 measured healthy sessions at put=66/134
within seconds; r54's third-session rank2 discovery read p=67, g=67 (a
LIVE put), the r48 seeding set last_get=67, and the client's first push
(entry 0) was never decoded - the channel_pool_add spin. Always start at
slot 0; a genuinely stale block is still handled by the existing put-drop
resync. Also make the CE put-snapshot diagnostic per-rank (the channel
struct iterated is a local copy, so the old per-channel stamp let the
first rank spend the whole session budget) and raise its cap for a
third-session rank2 to keep logging through a stall.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
physical forward fails (ISSUE-0002)
r51/r52 root evidence: the second session's GR launch was forwarded to the
physical engine; the backend timed out (qmd_rel=5 want=6 after 5 s) while the
hold resolution applied only the *stream-recorded* channel release. The QMD
launch completion semaphore (the word the client polls in its launch-
completion wait) is carried by the GR candidate (gr_rel_va/gr_rel_payload),
not by the release records, and nothing authored it on failure - the client
spun forever in the completion wait and the pump went idle (pushes=1207,
pending=499, crel frozen).
Fix:
- a GR hold waits for the backend's bounded outcome (12 s bound vs the
backend's 5 s poll) instead of the 500 ms CE copy bound, so the release is
never authored while the physical submission is still writing guest pages;
- on hold resolution without a successful hardware copy (timeout, abort,
expiry, or a release0 page the backend could not observe), the QMD release
is software-applied forward-only (read/compare, absolute payload write) -
idempotent against a late engine write and never rewinds the tracker;
- a GR capture whose request did not queue (refused/backend busy/hold active)
authors the same release inline when the CUDA bridge is disabled (the
bridge job owns it otherwise);
- new work_guard counter gr_sw_rel names how often the fallback authored a
release, and each write logs its va/payload.
Validated: c1 GREEN, c2 GREEN in the same VM (r54; CE->GR, mail + VADD
STATUS OK). In that run the forward succeeded so gr_sw_rel stayed 0; the
timeout branch is the one r52 proved is reachable.
|
| |
|
|
|
|
|
|
|
| |
r50 regression: requiring method-stream plausibility for the window source
rejected valid non-method push prefixes and corrupted c1 (VADD bad=32767),
so that gate is reverted. Narrow it to the r49 failure mode: a window read
returning all zeros cannot be a real page (the paired base page is real), so
fall through to the learned/discovered resolvers. Non-zero window content is
trusted exactly as before.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
resolvers (ISSUE-0002)
r49: the second session's CE push pages beyond the paired base page read
all-zero through the linear window guess; because the window read
'succeeded', the learned/discovered/targeted resolvers (src=3) were never
tried and every follow-up push was held as unreadable (crel frozen, client
spinning). A valid push's first chunk always parses as a method stream, so
require that for the window source on the first chunk only and fall through
otherwise. Correct window reads are unaffected.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(ISSUE-0002)
r48: the layout USERD of the second session's rank0 was accepted with the
previous session's residual PUT=134; the pump consumed 34 stale slots, then
the guest's fresh counter reset PUT to 1 and the pump wrapped: last_get never
matched the guest's sequence and the live first push was not processed. The
client was later seen pushing 216-byte no-release entries with crel frozen.
A fresh channel's first push always publishes PUT<=1 and the client waits for
its release before a second push, so a PUT>=2 at discovery is residual: seed
last_get past it and resync to slot 0 when the guest's own counter reset
drops PUT below put_prev. Clear the wait state once entries are consumed
without a reset so later genuine wraps keep the normal wrap path.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
r47 guest truth (channel_info walk in the hung second client): every CE
channel's GP_PUT/GP_GET GPU VAs are ring+0x2008c / ring+0x20088 and the live
rank0 USERD is the layout block at fb 0x90000 (the emulation's offsets were
right all along). The coherence gate required g <= p, but the GET word is
GPU-owned and holds leftovers (session 2 rank0: PUT=1, GET=136 from the
previous session) - so the live block was rejected forever (r44 strict never
accepted; r42/r46 latched the stale registered candidate). Accept the CE
layout block when the PUT word is plausible; the pump tracks ch->last_get
and rewrites GP_GET as it consumes entries.
|
