mirror of
https://github.com/ARMSX2/ARMSX3.git
synced 2026-08-24 16:58:52 -07:00
jpolo1224
ea52e9bef4
Five earlier attempts at catching this hang keyed on something STOPPING -- frames, then lock traffic -- and every one missed it, because nothing stops. Measured on the hung device: PPU[0x1000000] burning 4.36s of CPU across 4s of wall clock, more than a full core, while rsx::thread spun on NV406E_SEMAPHORE_ACQUIRE. Tales of Xillia 2 white-screens when its Bandai logo is skipped, and the guest's main thread is not blocked at all -- it sits in a tight guest-side wait loop, making no syscalls, taking no locks and writing no log lines. A frame-based detector saw frames still flipping, a lock-based one saw a peak of 10 locks/sec to fall from, and neither was wrong about what it measured. They were measuring the wrong thing. So look for the opposite of a stall: a thread that is RUNNING -- no cpu_flag::wait, meaning not parked in a syscall -- whose cia has not left a 1 KiB window for 30 seconds. A spin loop is a few instructions branching to themselves; ordinary execution walks cia across the binary many times a second. Threads waiting in a syscall are skipped, so an idle game cannot trip it. Dumps twice, 15s apart, so the second shows whether cia moved at all between them, and reports its own state every 10s: threads tracked, longest spin, dumps taken.
