A coprocessor's reset and BAR2, and the guard that keeps the host up, 2026-11-04
768: an XGS 3300's host does not come back when its coprocessor is reset under the loaded driver. Until now the answer was to see the reset coming - feeder.py's watch and octep's quiesce - and a reset nothing announced still froze the host. The runs below, on the lab's first XGS 3300 (vendor version 23) on 2026-11-04 (UTC), followed a read of the PCIe side, stage by stage, and found what hangs: **a read of BAR2
- the window into the coprocessor's own memory - made in its reset.** BAR0, its registers, goes on answering through the reset, and its readiness register reads 0 from the reset on. So BAR2 is now read and written only while BAR0's readiness register holds its magic (1030), and with that the host lived a reset nothing announced, and a panic of the coprocessor's kernel that restarted it a second later - on both XGS 3300s, the second (vendor version 22) as well, the coprocessor taken up again in place each time.
The whole page, with how it was taken and what it does not show: A coprocessor's reset and BAR2, and the guard that keeps the host up, 2026-11-04.
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.