mirror of
https://github.com/ARMSX2/ARMSX3.git
synced 2026-08-24 16:58:52 -07:00
jpolo1224
d65a603547
Seven detectors over as many reproductions, none of which caught it. The final one settles why: with cia sampled once a second, the guest threads are found at a DIFFERENT address every time -- 0x011f63ac, 0x00278268, 0x008ac3a4, 0x0141512c -- so the best repeat count never exceeded 1. The thread is not parked anywhere. It executes a great deal of varied guest code at over 100% of a core while making no progress, consistent with sys_ppu_thread_yield at ~100 million. A busy-wait that does real work each iteration cannot be found by watching for something to stop, which is what every one of these tried, in a different place each time. What was learned and is worth keeping is recorded in the commits: frames keep flipping throughout (so no frame-based check can see it), lock traffic never ramps up because the hang precedes any workload, rsx::thread spins in NV406E_SEMAPHORE_ACQUIRE, and PPU[0x1000000] burns 4.36s of CPU per 4s of wall clock. The next attempt should start from a guest-side breakpoint or an instruction trace, not from another liveness heuristic. The structural fixes found along the way stay: on_frame_end no longer counts forced frames as guest progress, and check_frame_stall dumps guest threads rather than only reporting. Both are correct independently of this hunt.
