| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(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.
|
| |
|
|
|
|
|
|
|
|
|
| |
r46 evidence: in a second session the CE rank0 layout probe at ring+0x10000
read a transient incoherent pair (-EINVAL) at discovery and the old candidate
list immediately latched the stale registered pool-relative offset (another
rank's previous-session USERD, frozen 1/1), hiding every later GP_PUT. For CE
channels enforce the ring-derived layout block only, retry until it reads
coherent, and never fall back to the registered/neighbour candidates. A
bounded (+3s, +33s) FB sweep logs the live put/get block when the layout
never becomes coherent.
|
| |
|
|
|
|
|
|
|
|
| |
r43/r44 showed the strict CE branch never engaged for the second
session: no sema-chan/sema-put line for c2's CE channels at all (the
layout probe did not accept), so c2 stalled before any USERD was
selected. Restore the r42 validated-layout behaviour (c1 green, c2
progresses to the known crel=216 stall) until the layout probe's
failure in session 2 is instrumented. The next experiment must log the
CE branch's ring-validation and layout-probe rc/p/g per pass.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
(ISSUE-0002)
The pump calls svc_chan_userd before the ring is pinned; the old
candidate list then accepted the registered pool-relative userdMem
offset (stale cross-session 1/1) and userd_ok froze it for the session
(r42 c2 rank0 userd=0xf0000 while the layout block 0x90000 is the one
the guest writes). For CE channels: wait for the ring, validate its
entry0 (a CE push VA + len), then accept the layout USERD at
ring+0x10000 even while idle; anything else returns -ENOENT so the next
pass retries. Registered-offset candidates remain for non-CE channels.
|
| |
|
|
|
|
|
|
|
|
|
| |
(ISSUE-0002)
r41 c1 regressed: svc_lookup answered rank4's fresh gpfifo VA with an
unrelated FB offset (0x90000) and the idle acceptance cemented the wrong
USERD (ring+0x10000 of the bogus base). Gate the layout-derived USERD on
the ring's entry0 decoding to a CE push VA + plausible len, the same
check svc_ring_autopin already uses; a bogus ring now falls through to
the previous candidate list.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(ISSUE-0002)
svc_chan_userd now prefers the layout-derived CE USERD
(ring_pa + 0x10000 in the ring aperture) and accepts it while idle, so
a second session cannot latch onto the registered pool-relative offset
when that alias holds a DIFFERENT rank's stale USERD: r40 c2 rank0 read
rank3's stale 1/1 at FB 0xf0000 and the pump never followed rank0's own
GP_PUT (guest GPUT mapping for gpFifoGpuVa proves ring+0x10000).
guest_pin_stream.va_to_pa drops translations outside the registered
guest-RAM windows so BAR1-phys addresses (0x70000xxxxx) are no longer
injected as SYS pins; r40 rank2's ring resolved to the bogus
pa=0x70000c0000 ap=SYS and read 66/66.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
transition (ISSUE-0002)
r31 experiment: log every CE GPFIFO entry read (budget raised, reset per
session), every svc_decode_stream call, and the two exits that consume an
entry without a decoded release (norel hold / unread slow path). Names the
exact exit taken by the second session's follow-up pushes.
|
| |
|
|
|
|
|
|
|
|
| |
The conflicting-injection race handled for pool releases also poisons push
pages: when the later store wins the pin table, the pump reads a page the
client never wrote, the push fails the method-stream plausibility check and
its releases never decode. When the primary read is implausible (or
unreadable through every source), try the recorded displaced translation
once before the rescue/hold paths; content plausibility stays the arbiter.
Bounded sema-pushalt evidence lines (32/session).
|
| |
|
|
|
|
|
|
|
|
| |
per session (ISSUE-0002)
The ipin store/lookup probes served their purpose (the displaced-pin race
is understood and handled); keeping them consumed the shared per-session
counter_rel_dbg budget before the release path could log, which left r25's
second-client stall blind. Remove them and reset svc.entry_log in the
session flush so the next session's sema-push decode lines are visible.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
(ISSUE-0002)
Two host tools can inject conflicting PAs for the same pool-semaphore VA
page; the pin table is one entry per page, so the later store won and the
release written through the loser was invisible while the client polled
the winner forever (observed r22/r24: fresh va=0x121000000 -> pa matched
the client pagemap; a later stale pair overwrote it, the single release
write landed on the stale page, and the second client spun in UVM
registration). Remember the displaced pair and write the release to it as
well: forward-only and read-back proven, best effort, sequential clients
only (documented in the helper).
|
| |
|
|
| |
store/lookup probes (ISSUE-0002)
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
(ISSUE-0002)
Hold pool-VA releases for 5s after a channel registration so the fresh
session injection supersedes the previous client's translation, defer a
readable-zero pool word instead of absorbing the write, and keep an INC
pending entry alive until the word is non-zero. Second-session releases
still resolved to the previous client's page (observed: write to
0x122090000 while the fresh injection at 0x134590000 stayed zero) - the
stale-pin source is the remaining lead; diagnostic pool-rel candidates
added.
|
| |
|
|
|
|
|
|
|
|
| |
A CE (pool) release that reaches svc_counter_release_apply finds no
counter slot and was discarded. The launch path normally writes pool
releases via svc_sem_write, but skips it whenever it believes the value
was already applied (or the word was unreadable at decode time); the
second session's early releases were lost exactly there. Apply
forward-only absolute through the pool writer instead - idempotent for
a monotonic tracker, so a duplicate can never double-count.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
(ISSUE-0002)
The push-buffer pairing bitmap (svc_pb_done), its pass budgets
(svc_pb_passes/svc_pb_idle/svc_pb_last*) and the GR ring bitmap
(svc_gr_ring_done) are boot-scoped, but svc_session_flush() only wiped
the pins they stood for. The next client reuses the same CE/GR ranks,
so discovery skipped every rank, its push pages could never be paired,
and its decoded releases were dropped ('no slot registered'): the
guest waited on a tracking semaphore that could never advance - the
second-client hang. Re-arm the discovery state in the flush.
|
| |
|
|
| |
silent exits (ISSUE-0002 diagnosis)
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
(ISSUE-0002 diagnosis)
Bounded instrumentation: every svc_sem_write into 0x7924_xxxx_xxxx..0x7926
records (h, va, pa, aperture, resolver provenance, value, write rc,
read-back ok/value, pool) so the second session's translations for the
same VAs can be compared against the first session's. The second client
spins in uvm_gpu_retain_by_uuid -> uvm_page_tree_init ->
uvm_push_end_and_wait -> wait_for_entry_with_spin (guest kernel stack,
sysrq-l) waiting on the channel tracking semaphore; these lines will
name the PA the release landed at.
|
| |
|
|
|
|
|
|
|
|
| |
The pin-stream tool follows the live client's pid, but its injected
entries survived the session flush. The next client reuses the same VAs
with new PAs, so stale injections resolved it through the previous
client's pages - the second-client exit hang. The 10/10 gate never ran
the stream (green); the handover harness does, which is why r3-r10 saw
the hang. The queue is drained on svc_thread (svc_handle_map_add), the
same thread as this flush, so the clear cannot race it.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
sleeping in the VA-space walker (ISSUE-0002)
Two host-side defects from the r9 capture:
1. The session-end flush was executed at the top of svc_rebuild without
checking whether the next session had already started registering:
in r9 it ran between the second client's first and later channel
registrations and wiped its freshly learned state mid-setup. The
flush now runs on svc_thread only (the sole writer of the discovery
state), at the top of its loop; a first channel of a new session
waits on svc_sess_flush_done before registering, so the wipe can
never land after that session's state exists and the new session
still starts from a clean slate. Scans abort on the pending flag so
the wait is bounded, and channel_del wakes svc_thread so the flush
runs promptly instead of waiting out a pass.
2. svc_walk_vaspaces held svc.vas_lock (spinlock) across svc_gmmu_walk,
whose guest reads go through vfio_dma_rw (mutex, may sleep) - the
'BUG: scheduling while atomic' in the r9 service log. The walker now
snapshots the published VA spaces under the lock and walks unlocked.
|
| |
|
|
|
|
|
|
|
|
|
| |
in the session flush (ISSUE-0002)
The second client still resolved through the first client's pages because
three session-scoped tables survive svc_session_flush: svc.pin (the primary
learned VA->PA table, consulted before every other source), svc_cnt_der
(serves a cached PA without re-proving it) and svc_hot (scan bitmap).
Clear all three with the rest; svc.ipin is left alone (injected pins are
the external pin tool's domain).
|
| |
|
|
|
|
|
|
|
|
|
| |
A redundant channel delete (a FREE for a handle that never registered, or
a repeated delete after the session already ended) found the channel set
empty while the next client was already starting and re-armed the flush,
which then executed mid-startup and wiped that client's discovery state
(and dropped its pending releases): the client spun at its first channel.
Track whether a session's channel has registered since the last flush and
request the flush only on the true existed->empty transition; redundant
deletes are inert.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(ISSUE-0002)
A second CUDA client in the same guest runs in a new UVM VA space that
reuses the same VAs backed by new pages. The service's discovery state
(merged scan map, pinned push-buffer pairs, discovered page-directory
latch, direct_base, pool-PA cache, CE ring-done ranks, retry queue,
forward-release records, GRCE dst ring records, pending releases, VA
spaces) is learned from the live client and was never reset, so the next
session inherited translations for the previous session's pages: its
rings never auto-pinned, releases queued unresolved in svc_pending and
the client spun at its first channel. One clean boot always works, so
make the next session look like one: when the channel set empties mark
a flush; the next rebuild (forced immediately) resets the same state a
fresh boot starts with, and the new client re-discovers from its own
content.
|
| |
|
|
|
|
|
|
|
|
|
| |
Wedges (WEDGE-COMPARE-r7-vs-r10.md) wrote the pool completion to pa==va
(0x121000000, src=trusted) instead of the guest's real page (greens use
src=pin); the read-back proof cannot catch identity because the SYS
aperture reads/writes accept any address, so it cached and the guest's
first tracker wait never woke (kernel logging stops at client init, guest
wedges). Never accept or cache a pool VA->PA resolved to an identity page:
guard lookup/cache/store and every resolver source; a rejected identity
misses, so the release queues in svc_pending[] until the real pin lands.
|
| |
|
|
|
|
|
|
|
| |
the cudaMalloc spin)
Every build since m143 reports BAR1=512MB to the guest and stalls the
client inside its first cudaMalloc; the m140 green reference reported
BAR1=256MB with the same 512 MiB shadow. Revert to the physical aperture
size as the single-variable probe for ISSUE-0001.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
cudaMalloc spin)
m140 published every channel with the pass-computed put and GR clients
advanced (green counter publish val=put). The H3 change restricted the
end-of-pass site to CE and moved GR to the safety-net early call, which
reads GP_PUT from the snapshot USERD and returned 0 on live GR channels
while the pass's own put was 1. GR never published; victory_mail spun at
100% CPU in the first cudaMalloc (wchan=0). Publish GR here again; the
early call remains the fallback for early-continue passes and both are
monotonic.
|
| |
|
|
|
|
| |
readable; walk-verdict telemetry (FORENSICS-grv6-ring fix A)"
This reverts commit d246c02500a6eb41f88e7aae1febb6e800668d73.
|
| |
|
|
| |
FORENSICS-grv7-counter): release targets the learned release VA, publish targets the ascending counter slot
|
| |
|
|
| |
FORENSICS-grv7-gate); keep read-only dbg telemetry
|
| |
|
|
| |
walk-verdict telemetry (FORENSICS-grv6-ring fix A)
|
| |
|
|
| |
(FORENSICS-grv5 E1/E2)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
FORENSICS-grv3: the FB discovery worked for ranks 0..2 (content-discovered +
auto-pinned ap=2, ring_auto 6->9, gpfifo done 89->110, gr_rel 0->3), but the
guest only ever wrote ring entry0 for those three ranks during the scan
window, and the discovery epoch took its 60-pass cap and retired - the re-arm
existed only on channel registration - so the remaining ~8 minutes of guest
life had no scanning at all (890 "capped" messages, no pass after ~4189).
The first pin was also ~3.5 s late because the 6 GiB RAM walk ran before the
FB scan.
Changes:
1. Periodic re-arm (FORENSICS-grv3 sections 4-5A). Taking the epoch cap no
longer retires discovery: the pass count resets, discovery rests
SVC_GR_CONTENT_COOLDOWN (30 s) and then starts a fresh epoch for as long
as any registered GR channel still lacks a ring. A registration batch
still re-arms immediately (and now also clears the cooldown). When every
registered GR channel has a ring, discovery stops with a single
"discovery idle" log line. Passes stay one per 2 s and the cap/cooldown
bounds the scanning duty cycle, so a permanently missing ring cannot
hot-loop.
2. FB scan first + fast path (FORENSICS-grv3 section 5A). The emulated-VRAM
scan (direct host reads, milliseconds, bounded to SVC_GR_CONTENT_FB_LIMIT
at a page stride) now runs before the RAM walk and records ring
candidates without requiring a push candidate. Push candidates are kept
across passes (the ctx-init pushes are content-stable), so when every
ring-carrying rank already has a push the pass pairs right after the FB
scan and skips the RAM walk entirely: a late ring submission becomes
visible within one 2 s pass instead of after a full re-scan.
3. Descending RAM walk with early exit. The push (release-group) walk now
starts at the top of guest RAM - the same reasoning as the CE content
rescue: the guest's work allocations live in the high RAM block (grv3
pushes at 0x1028f...0x12df8..., 4.0-4.8 GiB) - and stops as soon as every
ring-carrying rank has a push candidate, so the pass ends in about a
second instead of a full 6 GiB walk. RAM ring candidates are still
recorded here for boots whose ring is not in FB.
The pairing gate is unchanged: entry0 exact, the push parses end-to-end, the
release group sits at len-20 with this rank's slot and payload 1, and the
USERD at ring+0x2000 reads plausibly. Wrong or stale candidates pin nothing.
No module parameters were added or changed.
Not included (deliberately): the notifier/event completion path from
FORENSICS-grv3 section 5B. Section 3 lists it as the leading hypothesis only,
never observed live (the relevant logs are debug-gated), and 5B gates it on
this change showing the guest posts nothing more; the sema_dbg=Y experiment
is the discriminator. No speculative change was made.
Evidence: FORENSICS-grv3 sections 0, 4, 5A; 11-hostdmesg-grv3-r1.log
2727-2735 (FB pins), 2820-2823 (cap), 4060-4062 (capped tail); m104
17-host-m104-r1.txt:164-283.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(FORENSICS-grv1 R1)
FORENSICS-grv1: the grv1 campaign ran the H1 content pass to its 60-pass cap
with zero pairs. svc_read() is vfio_dma_rw over guest DMA addresses, so the
4 GiB guest-RAM scan found all eight GR ctx-init push candidates (len 0x2a4)
but no page-aligned ring entry0; the ring lives in the emulated vidram
aperture (vgpu->bars[1].vaddr), where m104's green ring was FB
0x140000 + R*0x3000. The trusted walk also missed (the ring VAS is
unpublished: VAS[0] root empty, VAS[1] has no usable PD0 for the window), and
the H3 early publish was a no-op (put=0 from the pool-relative registered
USERD at 0xc32000, which reads zeros in FB).
Changes (one coherent commit):
1. svc_gr_content_pin() takes the ring's aperture. The ring page and the
USERD at ring+0x2000 are read through that aperture; the push page and its
release group stay guest RAM (SYS); the hot-page bitmap (guest-PA indexed)
is only touched for a SYS ring. FB rings log
"content-discovered GR ring ... -> fb 0x...", RAM rings keep "-> pa=...
ap=1". The gate is unchanged: entry0 exact (push VA + len), push parses
end-to-end, release group exactly at len-20 with this rank's slot and
payload 1, USERD readable (active pair or readable idle) - otherwise
nothing is pinned.
2. svc_gr_content_discover() scans the emulated VRAM mapping after the RAM
pass for every rank that has a RAM push candidate but no guest-RAM ring
candidate, at a page stride, bounded to SVC_GR_CONTENT_FB_LIMIT (512 MiB,
matching the existing one-shot fbs scan bound), with the same entry0
filters and the plausible-tail check. Candidates pair with the RAM pushes
by length (0x2a4) and rank geometry, then go through the same full gate.
3. The 60-pass one-shot cap is now a per-epoch bound that re-arms on channel
registration: gsp_sema_service_channel_add() sets svc_gr_content_rearm for
GR channels (the guest recreates channels on every context retry), and
svc_gr_content_discover() consumes it and resets the epoch pass count. The
cap message is ratelimited and names the re-arm condition, so discovery
can no longer retire for the boot while the guest is still trying.
4. The registered userdMem base (pool-relative, reads zeros) is superseded by
the ring+0x2000 USERD probe through the ring's aperture; this covers the
grv1 "probe rc=-11 from the wrong base" case without a separate path.
No module parameters added or changed; the accepted recipe is untouched.
Evidence: FORENSICS-grv1 sections 0-5, m104 17-host-m104-r1.txt:164/169,
11-hostdmesg-grv1-r1.log:2308/2339-2347/2429-2435/2796.
5. The GR pin-branch "auto-pinned GR ring ..." line now carries ap=%d, so
the latch is unambiguous in dmesg (FB=2 for the content-discovered ring).
|
| |\
| |
| |
| | |
SPDX sweep, conventions (handoff-code-standards.txt)
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Editor defaults at the repo root; kernel/ uses Linux kernel style (tabs,
width 8, ~80 cols) and userspace//tools/ use LLVM base with 4-space indent
and ~100 cols. Configs govern new code and edited hunks only: existing
files are not to be mass-reformatted (recorded in the file headers and
docs/07-developers/onboarding-and-standards.md 3.1/3.2).
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
(FORENSICS-v2 H3 + anomaly 6)
FORENSICS-v2 H3: svc_counter_publish() was reachable only at the end of a
fully pumped channel; when a GR channel's ring or USERD cannot be read the
per-channel loop early-`continue`s above that call (USERD not resolvable,
GP_PUT unreadable), so pub_calls stayed 0 even with all 20 GR counter slots
registered and the client's tracker waiting on them. Duplicate the publish
into the safety-net block at the top of the per-channel loop, next to
svc_counter_autoreg/svc_counter_flush_pending:
- the value is a real GPFIFO put read from the channel's registered
USERD; when the USERD is not readable nothing is written, so a guessed
put can never advance the client past work the pump cannot see;
- the target is the proof-gated slot registration (injected pin or the
read-back-validated derive), never an unproven page;
- the same relay-hold guard as the end-of-pass call applies.
The end-of-pass site now publishes for CE channels only, so a GR pass does
not publish twice.
Anomaly 6: an earlier-derived counter_pa could disagree with a
later-arriving injected pin (r1: derived 0x123a43ff0 vs pin-backed
0x123a28ff0) and nothing re-checked the pin while counter_pa was already
registered - a publish would then advance a page the client never polls.
svc_counter_autoreg() now re-checks the rank's slot against the injected
pin on every pass and re-registers (under chan_lock) on a mismatch, which
also makes the new publish proof-gated through the pin.
Evidence: FORENSICS-v2 H3 + anomaly 6; 11-hostdmesg-v2-r1.log:2429-2714
(20x "not at fb ... probe rc=-11", pub_calls=0, gr_rel=0)."
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
walk, content fallback) (FORENSICS-v2 H1+H2)
The v2 campaign confirmed the CE-side fixes work (89/89 releases applied,
pool page resolved src=trusted) but the stall moved one phase later: the
guest authors its eight GR context-init pushes and the host never reads a
single GR GPFIFO entry (ring_auto=6 CE-only, pub_calls=0, gr_rel=0,
work_gr req=0). The GR ring VA 0x200200000+R*0x3000 and its USERD are
never resolved: svc_gr_ring_autopin only tried FB conventions,
userd-derived FB candidates and existing pins (FORENSICS-v2 H1/H2).
Three bounded, content-gated extensions:
1. Trusted walk (H1): try svc_lookup_trusted() for the ring VA - the
driver-published VAS walk / self-discovered directory chain that
resolved the CE pool page in v2 ("pool-pa ... src=trusted",
11-hostdmesg-v2-r1.log:2313).
2. Both apertures (H2): every ring-derived and registered USERD candidate
(svc_chan_userd) and every userd-derived GR ring candidate
(svc_gr_ring_autopin) is tried in the registered aperture first and the
other one second; v2 read the GR USERD through FB and got 0/0 while the
same boot's pushbuffer pins are sysmem.
3. Content fallback (H1 last resort): one self-gated, 2 s-rate-limited,
60-pass-capped 64 KB chunked scan of registered guest RAM locates, per
rank 0..7, the release-group page ("200426c0 00000002 0400ffXX
00000001", group at push len-20, page-aligned push at VA
0x200400000+0x400000*rank, m104/handoff 2576-2597 geometry) and the
ring page whose entry0 is the exact (push VA, len) pair. A pair is
pinned only when the full gate passes: entry0 bytes exact, the push
parses end-to-end as a method stream, the release group is exactly at
len-20 with this rank's slot and payload 1, and the USERD at +0x2000
reads a plausible get/put pair (or a readable idle 0/0). Anything else
pins nothing.
All candidates share the existing rule: a wrong guess costs a failed
probe, never a wrong pin. Evidence: FORENSICS-v2 H1/H2, m104
17-host-m104-r1.txt:169-171, v2 dmesg 11-hostdmesg-v2-r1.log:2313-2714.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
(ISSUE-0001)
svc_rescue_try() substitutes exactly one candidate page and requires every
other page of the entry to resolve through svc_lookup_trusted(). For a
multi-page push whose pages have no translations yet that precondition can
never hold: the content scan finds the release-group page by content, but
the pages that need a candidate are exactly the ones missing from every
trusted source. That is the stalled-boot class named by SA-STALL (entry
va=0x120021db8, len=12816, release #39; 17-host-m84-r1.txt:841-842), where
the userspace pin stream was the only supplier of those translations.
Add svc_rescue_run_try(): once content has anchored one page of the entry
(release-group candidate from the matcher, or the verified window base),
read every page of the entry directly from the same signed page delta in
both physical directions, validate the assembled buffer exactly like the
single-page rescue (full method-stream parse + the channel's exact next
release), and only then pin every page of the run. A failed direction
pins nothing; a passed validation is content proof for every page. Wire it
into the svc_pb fast path, the hot-page scan and the descending RAM scan,
ahead of the unchanged single-substitution try.
This makes the pump able to consume a starved CE push with no watcher pins
and no pre-existing per-page translations; the watchers become pure
accelerators. New counter resc_run is printed when non-zero.
Evidence: ISSUE-0001, SA-STALL 3.2/3.4; 17-host-m104-r1.txt entry[38] and
17-host-m84-r1.txt rescue rejects.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
(ISSUE-0001)
svc_pb_discover() ran with a flat 12-pass budget for the whole boot and
then retired, even when a registered CE channel had no content-discovered
push-buffer base yet. A channel that appeared after the budget was spent
(including one reappearing with a new client session) then had no paired
window, so every push went through the slower per-page rescue and the
userspace watcher pin stream.
Stop the pass only after SVC_PB_IDLE_PASSES consecutive passes with no
new base AND with every registered CE channel either paired or having a
base recorded for its release slot, with a hard cap (SVC_PB_PASS_MAX) so
a channel that genuinely has no base page cannot scan forever. The 3 s
rate limit and chunked walk keep the service thread responsive; the
per-pass log now carries the idle count.
Evidence: ISSUE-0001; v2-r1 counter freeze (pb=6/12, see
backups/evidence-20261002-victory/11-hostdmesg-v2-r1.log) and the SA-STALL
class where the CE window was reached only after discovery had stopped.
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(ISSUE-0001)
svc_pd_discover() latched svc_pd_tried before its first scan, so a call
that ran before the client's page tables existed (or before enough
verified push-buffer pairs were known) disabled the one kernel-native
source that translates pool/push windows the content-scanned map and the
published directories miss, for the rest of the boot. That source is what
svc_lookup_trusted() and svc_pool_pa_resolve() fall back to when the
userspace watcher pins race.
Make discovery retryable and evidence-driven: an attempt that cannot run
does not latch, a scan runs only when the sample-set fingerprint changed,
and the total is capped at SVC_PD_ATTEMPTS_MAX per boot - the same order
as the old per-pairing re-arm, which this supersedes (the stale re-arm in
svc_pb_pair is removed).
Evidence: ISSUE-0001, SA-STALL 3.2/3.4 (the deferred pool release of the
last CE push with no translation when watchers race).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(ISSUE-0001)
svc_pool_pa_resolve() could translate an UVM pool/waiter page only from
watcher pins, the read-back cache, the self-discovered directory and a
targeted rm_mem scan. When the userspace watcher races a boot and the
self-discovered directory has no entry yet, a starved completion release
sits in svc_pending[] forever (p13-r4: applied frozen at 89/90, gr_rel=0),
the guest tracker never wakes and CUDA blocks at DEVICE. Add:
- svc_walk_vaspaces() (the driver-published page directories - the walker
svc_lookup_trusted always used, previously absent here);
- a final proof-gated svc_lookup_trusted() fallback (also the only path
that triggers svc_pd_discover()).
Both read-back proven like every other source. Plus per-entry starvation
telemetry (tries + bounded logs) so a future stall names the exact va.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
kgrobjPromoteContext_IMPL marks each ctx buffer initialized when the
REPLY's promoteEntry[i].bInitialize is set:
if (!params.promoteEntry[i].bInitialize) continue;
kgrctxMarkCtxBufferInitialized(...);
The flag is the server's initialized-ACK, so the correct emulation reply is
a verbatim echo (the physical backend owns residency; the control answers
SUCCESS). 7ce387f3 cleared the flag believing the check inverted - that
skipped the mark and left the RM re-promoting the same buffers forever.
Restore echo semantics with the source-cited comment.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
kgrobjPromoteContext_IMPL marks a context buffer initialized only when the
REPLY's promoteEntry[i].bInitialize is clear; echoing the request back kept
the flag set so the RM re-promoted the same contexts indefinitely. Clear
the flag on the echoed reply (per-entry, 5 entries observed per call).
Note: this aligns the reply with the caller contract but did NOT by itself
unblock the observed cudaMalloc stall (client still reaches DEVICE then
spins; zero GR ring content in VRAM) - kept because the old behavior was
wrong and the flag gates kgrctxMarkCtxBufferInitialized.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
window
The guest's first RmInitAdapter intermittently fails: GspStatusQueueInit
gives the status-queue link only 4 s (message_queue_cpu.c: timeoutUs =
4000000) and the first boot attempt can burn it, after which the RM tears
down, leaks the device and retries; the surviving retry leaves the GR/ctx
state degraded, which is the persistent cudaMalloc stall class.
Changes:
- gsp_rm_emu_poll: parse-retry cadence 250 ms -> 50 ms (the 250 ms tick
consumed a fifth of the guest's budget per attempt).
- gsp_rm_emu_reset: clear last_parse_retry so a new boot gets a fresh
retry budget; take stat_lock while clearing queue cursors so a sema
event post cannot race the reset.
- gsp_rm_emu_on_booter_done: on GSP_INIT_DONE send failure re-arm the
retry path (parsed/active were already set, so the poll loop would
never retry).
- gsp_rm_parse_queue_chain: free the previous ptes before re-alloc so
retries and post-reset re-parses do not leak.
- gsp_rm_post_channel_event: never post events across a queue reset
(parsed gate).
guest_kprobes.sh: add rpcs/rpcp transport probes (the direct RPC-wait
symbol is notrace in 570.144) and ccset entry/return probes for
rmapiControlCacheSet so a stall names the control whose reply breaks the
guest's control-cache bookkeeping.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The counter slot for GR rank r is 0x20400fec0 + (TOTAL-1-r)*0x10 with
TOTAL the fixed pool total. The autoreg used a live high-water channel
count instead; channels register progressively, so an early pass with a
partial count (16) registered the ranks present at the wrong slots and
every later rank's correct slot was then rejected as owned. Result:
ranks 10..19 never got a counter, no counter was ever published, and the
client's userspace tracker never advanced (cudaMalloc stall while the
guest RM polled MC_SERVICE_INTERRUPTS).
Validated on a live boot: 20/20 slots registered with 0 collisions
(previously ranks 6..9 installed at the n_gr=16 mapping and ranks 10..19
rejected).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ring+userd) + GR ring userd-derived candidates
guest_pin_stream.py now resolves translations entirely from guest truth via
/proc/kcore + a manual page-table walk (no QMP races): the CE semaphore pool
and pushbuffer memory from the UVM rm_mem structures, and each channel's
GPFIFO ring + GPPUT from the tracking semaphore's embedding uvm_channel_t
(channel_info located by its gpFifoGpuVa value). This removes the watcher
pipeline's flakiness on the cudaMalloc stall class (missing pool/pushbuffer
pins).
gsp_sema_service.c: svc_gr_ring_autopin tries the guest-registered USERD
memdesc base as a ring candidate (the fixed FB convention only matches when
the guest's VRAM allocator happens to reproduce the old layout), plus an
optional (gsp_sema_dbg) one-shot FB scan + raw-word diagnostics when every
candidate fails.
tools/cuda-ab/p2: self-checking arbitrary-kernel acceptance suite (10
programs: sequential launches, shapes, params, smem/GEMM, streams, malloc
churn, printf+error, FMA benchmark, mixed, managed probe) with host oracle
expectations and a guest runner.
|
| |
|
|
| |
accepts -1g/-2g
|
| |
|
|
| |
offset span 33 pages; tails read the next reloc record)
|
| |
|
|
| |
passes; targets the guest cudaMalloc stall class)
|
