XGS 136 host with every coprocessor access timed: HTTP thirty times, six recoveries in place, 2026-11-04
1005: in the review before the release, the XGS 136's host stopped once in fourteen HTTP runs with a new connection for each response - no panic, no dump, and its hardware watchdog restarting it 128 s later. 988 is a stop of the same kind after a recovery in place. Read side by side, the two records point first to an access to the coprocessor that never completes: a host processor held in a read of the device, the others stopping behind it. On 2026-11-04 (UTC) the same load ran thirty times on the lab's XGS 136 (vendor version 21), with instruments that would name such an access. The host lived all thirty runs. In 683 million accesses to the coprocessor, the slowest took 158 us. Then #988's case ran six times with the same instruments - the coprocessor stopped, taken up again in place, and the ten-minute cron setting its clock back from 2097 about a minute and a half later - and the host lived all six (below).
The whole page, with how it was taken and what it does not show: XGS 136 host with every coprocessor access timed: HTTP thirty times, six recoveries in place, 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.