A ring's memory given back only once the coprocessor is known to have stopped with it, on the first XGS 3300 and the XGS 136, 2026-11-01
962, found by reading the code while answering a review: octep cleared a ring's enables and freed its memory straight after, with no read-back and no wait for the ring's IDLE bit; its management link waited a fixed two seconds after GOING_DOWN and freed whatever the target was doing; the RPC buffers went whatever was still on the command rings. And the coprocessor latches the output rings' addresses when its port opens and wrote the old ones again after a restart of the rings (OCTEON TX, "Rings before the handshake, and never restarted"), so even a ring known stopped could be written into once its memory had gone back. Nothing of this had been seen on an appliance.
The whole page, with how it was taken and what it does not show: A ring's memory given back only once the coprocessor is known to have stopped with it, on the first XGS 3300 and the XGS 136, 2026-11-01.
The discussion of this page is held in the project's GitHub Discussions. Showing it here loads giscus from giscus.app and GitHub, and writing in it needs a GitHub account - what that means.