diff options
| author | open-iov-agent <agent@open-iov.local> | 2026-10-09 17:48:02 -0400 |
|---|---|---|
| committer | open-iov-agent <agent@open-iov.local> | 2026-10-09 17:48:02 -0400 |
| commit | 8eb6a46d05d6156514624aa9f71e8666a4a9979b (patch) | |
| tree | de6bff13a7771fef9dfab3b5d7a5f67a00304fd5 /tools/firmware | |
| parent | 0c1cc6bcaed75e3dbe9f11a6690ff5ab99e0c05e (diff) | |
| download | open-iov-8eb6a46d05d6156514624aa9f71e8666a4a9979b.tar.gz open-iov-8eb6a46d05d6156514624aa9f71e8666a4a9979b.zip | |
vgsp-sema: never seed last_get past a discovery put >= 2 (ISSUE-0002)
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.
Diffstat (limited to 'tools/firmware')
0 files changed, 0 insertions, 0 deletions
