t_rx reported "no frame in 2 s (RWP still 0x000F)" on a healthy adapter after
the Ethernet suite had been run a few times. Page 15 is the giveaway: the app
never writes RRP, so ambient broadcast traffic fills the 15-page ring until
free = (1 + 15 - 15) mod 15 = 1, below _MAX_FRAME_PAGES (6). RBFI then drops
every frame -- correctly, that is what it is for -- RWP stops advancing
permanently, and a test that waits for RWP to move can never pass again for the
rest of the session.
t_rx now catches RRP up to RWP before waiting, declaring what is already in the
ring consumed. That is what a real driver does once it has read the frames out
and what netboot already does at start-up. It also leaves exactly the newly
received frame unconsumed at RRP, which is where the SPRAM/DMA suite reads, so
t_dma still has something to parse.
No gateware change: the drop behaviour was correct and the bug was in the test
app's failure to consume.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Roflin
2b0cbdd809