diff options
| author | Arthur Hanson Rasmusson <arthur@vgpu.io> | 2026-10-21 00:24:11 -0400 |
|---|---|---|
| committer | Arthur Hanson Rasmusson <arthur@vgpu.io> | 2026-10-21 00:24:11 -0400 |
| commit | 380469ee70dc4d3f1f695f807da0b0bfe7d5d3ba (patch) | |
| tree | 10b6cc9b4056ca9949af1abf08ed036a0056def7 /scripts/test_vgpu_stack.sh | |
| parent | 1c37e483c205eff947de33a37545a07af71a5d73 (diff) | |
| download | open-iov-380469ee70dc4d3f1f695f807da0b0bfe7d5d3ba.tar.gz open-iov-380469ee70dc4d3f1f695f807da0b0bfe7d5d3ba.zip | |
sema: r391f once-only GRCE inline writes - the sum=0 class root cause
A REPLAYED ring entry must not re-run its LOAD_INLINE_DATA writes. The
fill/copy ops were already gated by allow_ops (cleared for entry_replay),
but the inline-write gate was 'trusted || allow_ops' and a replay is
trusted by construction, so every re-decode of an already-processed push
re-wrote its inline bytes into the vidmem shadow.
victory_reduce's cudaMemset(d_sum, 0, 8) is exactly such an inline write.
Observed on r396: 'sema-grce: inline write dst=0x7845ef000000 ->
pa=0x7c00000 ap=vidmem bytes=8 data8=0000000000000000' fired 86 us before
the D2H readback of the same VA - zeroing the accumulator the launch had
just written (OUT-PAGE-POST val8=0000008000080000 = the correct sum) so
the client read zeros (sum=0, bad=1). The same replay rewrote the page
repeatedly (482 inline writes/boot). The r383 replay-capture path only
needs to CAPTURE the launch; the inline bytes were authored on the first
(non-replay) pass.
Diffstat (limited to 'scripts/test_vgpu_stack.sh')
0 files changed, 0 insertions, 0 deletions
