diff options
| author | Arthur Hanson Rasmusson <arthur@vgpu.io> | 2026-09-21 22:47:22 -0400 |
|---|---|---|
| committer | Arthur Hanson Rasmusson <arthur@vgpu.io> | 2026-09-21 22:47:22 -0400 |
| commit | 8a23a2567ceac9428e7140bf77f4eb3c493499fc (patch) | |
| tree | 7ea19c263b31f5038d04ccf51b5594974218b9ea /scripts | |
| parent | 55ffe494a749cf0ebf10b3146b8c59a4ab81aa5f (diff) | |
| download | open-iov-8a23a2567ceac9428e7140bf77f4eb3c493499fc.tar.gz open-iov-8a23a2567ceac9428e7140bf77f4eb3c493499fc.zip | |
kernel: fn-10 FREE timeout fixed - reply timing race (delay fn-10/47 replies)
The fn-10 (FREE) timeout was a driver-side reply-matching TIMING RACE,
NOT a reply-content bug. Verified exhaustively: reply is well-formed,
checksum valid (folds to 0), seqNum matches driver's rxSeqNum exactly
('Expected 75 got 175' via seqNum-poison experiment), function=10,
writePtr/readPtr land correctly, driver drains 1:1 (no lapping).
Yet rpcRecvPoll timed out only for fn-10/47-class RPCs during open/
cleanup. A 2ms delay before fn-10/47 replies eliminates all timeouts
(0 in a full nvidia-smi run) - matches real GSP-RM's natural reply
latency that the driver's reply-matching implicitly relies on.
Also: fn10 reply wire-bytes debug dump, writePtr readback confirm,
seqNum-poison experiment scaffolding.
Diffstat (limited to 'scripts')
0 files changed, 0 insertions, 0 deletions
