Not a fix. The game is expected to still render wrong; this answers one
question that three ring attempts could not, because all three differed
only in the notification path and all three failed with byte-identical
numbers (lost=70, pended=80, the same per-LBA repeat counts). Identical
results across different notification code proves the notification was
never the cause.
The remaining suspect is deliver_read_sector_without_irq(). It raises NO
INT1 by design -- it exists purely to refill the buffer so an in-flight
multi-sector DMA keeps draining. With one buffer the refill lands in the
buffer the DMA is reading and the transfer flows seamlessly. With a ring
it lands in a NEW slot, and nothing moves the read pointer there, so the
DMA starves mid-transfer and the guest retries: exactly the duplicated
Setlocs and 2-7 repeated sector reads observed.
ring_starved counts drains that found their slot exhausted while another
slot held unread data. Non-zero confirms it outright and the fix follows
(the no-IRQ refill must advance the read pointer: it is a continuation of
a drain in progress, not a new notification). Zero kills the hypothesis
and the ring line of attack stops.
ring_norq_refill and ring_read_moves give the supporting picture.
ring_probe.py reads the verdict; a build without the counters reports
no-instrumentation rather than a misleading zero.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Alex Vanderveen
2a078ca8d7