Queue 0x20 WAIT_REG_MEM on a label times out while the label holds an address-like value (Kena PPSA01746, Coral Island PPSA17226, Stray PPSA02100) #6558

Activity

1. xXPBSXx commented on Oct 15, 2026

   

   xXPBSXx

   on Oct 15, 2026

   ContributorAuthor

   More actions

   A fourth title with the same line, with a different value: Sifu (PPSA03001), main 03c4cb5e7 + #6236 (APS5_PLAYGO_UNLISTED_CHUNKS=absent; without that setting the title stops earlier at scePlayGo), Windows 10, RTX 4080 SUPER. PPSA03001_rV/run_214415.err (687 lines), line 38:

   [gpu] queue 0x20 WAIT_REG_MEM at 0x10214a3820 timed out after 1000ms (function 3 ref 0x1 mask 0xffffffff value 0x0)
   

   Here the awaited word holds 0x0, not an address-like value, so the two cases may differ. Line 39 (recorder: table miss (refusal 0), open batch writes it 0, snapshot write overlaps 0, pending completion labels 0, write-back completions 0) and lines 40-44 show the packets before the wait: SET_SH_REG, two RELEASE_MEM to other addresses (0578f910, 0578f8c0), SET_UCONFIG_REG c8010010 214a3820, WAIT_REG_MEM 00000013 214a3820 .... Line 49 is FATAL: unhandled exception 0xc0000005 (the title's own abort); whether it follows from the timeout is not established. The same queue 0x20 wait is described in #5983 (Lies of P, loading screen).

   Not verified: the picture, and what writes this label. No fix attempted.

   AI-assisted (Claude Code).
2. MarcZX10 commented on Oct 16, 2026

   

   MarcZX10

   on Oct 16, 2026

   Contributor

   More actions

   Thanks, the Sifu trace adds useful evidence that the timeout line is not limited to the address-like sampled values: this wait has value 0x0, a recorder table miss, and no overlapping recorder/open-snapshot write at the timeout. That is a distinct observed state from the Kena/Coral Island examples. I still cannot infer a cause or safely change WAIT_REG_MEM behavior from this single run; could you add Sifu as a fourth row in the issue body, and, if available, capture a repeat with APS5_TRACE_LABEL=<label> plus the following store/wait packets? That should show whether a write targeting this label is missing or simply never issued. The current log alone does not show an earlier write to 0x10214a3820.
3. MarcZX10 commented on Oct 18, 2026

   

   MarcZX10

   on Oct 18, 2026

   Contributor

   More actions

   Follow-up now that #4855 is merged: the current main has a way to capture both sides of this wait in one reproduction. For Sifu, please try a current-main build with APS5_PM4_RING=256, APS5_STALL_WATCHDOG_SECS=2, and APS5_TRACE_LABEL=10214a3820 (the label address from your log). The label trace records RELEASE_MEM packets targeting it; if the wait stalls, the watchdog prints recent submissions from each queue, including the producer queue if it submitted one. Please include the lines for the label and the ring dump around WAIT_REG_MEM, and add Sifu as the fourth title row if you rerun it. This should distinguish a missing label write from a write that was submitted but not observed; no change to wait semantics is implied yet.
4. xXPBSXx commented on Oct 19, 2026

   

   xXPBSXx

   on Oct 19, 2026

   ContributorAuthor

   More actions

   Rerun as requested on 18 October (Windows 10.0.19045, NVIDIA GeForce RTX 4080 SUPER, driver 610.74 per nvidia-smi; main 4ffb0cd12, Release; 560 s with pad input from a file; APS5_PM4_RING=256, APS5_STALL_WATCHDOG_SECS=2). Only counts, addresses and packet types below; the picture was not judged.

   Sifu (PPSA03001), PPSA03001_rNT/run_113244.err (43561 lines):

   • Three queue 0x20 WAIT_REG_MEM ... timed out after 1000ms lines (183, 219, 305), all function 3 ref 0x1 mask 0xffffffff. The awaited word holds 0x21285020 (label 0x102129d080), 0x2155a480 (label 0x1021558ca0) and 0x2148d3e0 (label 0x102148d380).
   • Each of the three values is the address of another label slot that appears in the PM4 rings as the target of DMA_DATA ... <addr> 00000010 00000004 followed by RELEASE_MEM ... <addr> 00000010 00000001, in queue 0x20 submissions: lines 20972-20973 (#3 serial 1672), 21191-21192 (#7 serial 7685) and 21574-21575 (#14 serial 7730). 0x2148d3e0 is also the target of a queue 0 WAIT_REG_MEM (lines 20521-20522, #3906 serial 7743). So the awaited word did not hold a stale 0 or 1 but the address of another slot of the same label area, as in the Kena and Coral Island rows above.
   • Stall report at line 312 (watchdog after 2 s): the stalled wait is the first of the five WAIT_REG_MEM of queue 0x20 #14 serial 7730 (t=160098.7 ms; lines 21545, 21550, 21555, 21560, 21579). Wait 4 (0x21433340) has its producer (DMA_DATA + RELEASE_MEM) in queue 0 serial 7729 (t=160098.4 ms, 0.3 ms earlier); wait 5 (0x21432d20) is produced by DMA_DATA + RELEASE_MEM in the same submission (lines 21576-21577); waits 1-3 (0x2148d380, 0x21433020, 0x214330c0) have no producer in the dump. The dump holds 256 queue 0 submissions (t=78258-160330 ms) and 14 queue 0x20 submissions. I did not check whether earlier queue 0x20 submissions had the same shape.
   • The last queue 0 submission is serial 7748 at t=160329.7 ms, 231 ms after the stalled submission; the title's own GameThread timed out waiting for RenderThread after 120.00 secs abort follows (line 21634).
   • APS5_TRACE_LABEL was not set for Sifu: the label 10214a3820 asked for on 18 October does not occur in this run (0 matches), the addresses change from run to run, so the label to trace is not known before the stall.

   PRAGMATA (PPSA02530), PPSA02530_rNT/run_114013.err (APS5_TRACE_LABEL=210c81bcc0 set): a different signature, not the state of this issue. The timeouts are WAIT_REG_MEM_64 with ref 0x63 and a small word value (0x1, 0x2), and the producer exists (queue 0 WRITE_DATA 00100200 <label> 00000021 00000063 00000000, e.g. line 285) but is submitted about 64 s after the wait (queue 0x20 serial 2 at t=18477 ms, first queue 0 submission serial 3 at t=82235 ms). It is listed only to avoid mixing the two cases.

   Not shown by these logs: what writes the address into the awaited word in the Sifu case (guest CPU or the emulator), and why waits 1-3 have no producer in the 256-submission window. I make no claim about the cause and propose no change to the wait semantics.

   AI-assisted (Claude Code).
5. EagleBearerYS commented on Oct 22, 2026

   

   EagleBearerYS

   on Oct 22, 2026

   Contributor

   More actions

   @xXPBSXx, if you have time for one more run of Sifu (PPSA03001) or Kena: Bridge of Spirits (PPSA01746): there's now a build that says why one of these waits wasn't satisfied.

   Branch fix/agc-label-wait-timeout-reason on EagleBearerYS/AnyPS5 (cf5462c, main a6dcea9 plus two commits). After each queue 0x20 WAIT_REG_MEM ... timed out after 1000ms line it prints one more line, once per label:

   [gpu]   label 0x… wait submitted at stamp N: <decision>; stores newest first: stamp … value 0x… queue 0x… opcode 0x…, …; now M
   

   • <decision> says whether the wait's value was checked when the wait was submitted, and if not, why: for example not checked at submission (queue 0x20 serial N writes it).
   • The stores are the last four recorded stores to that label, with the queue and the packet that made each one (0x49 is RELEASE_MEM, 0x50 is DMA_DATA), and the stamp at the time of the timeout.

   The environment of your 19 October run is fine, and no extra variables are needed. Each new label … wait submitted line, with the timed out line above it, is all we need.

   @MarcZX10, this complements the label trace from #4855: it needs no address in advance, and it shows the decision made at submission.
6. MarcZX10 commented on Oct 22, 2026

   

   MarcZX10

   on Oct 22, 2026

   Contributor

   More actions

   This newer diagnostic is a good fit for the Sifu signature: the reported waited value matches other label addresses, and the earlier 256-submission dump left waits 1–3 without a visible producer. The branch says it can explain the submission-time decision and recent stores without a preselected address. If you rerun Sifu or Kena, could you attach each WAIT_REG_MEM ... timed out line together with its immediately following label ... wait submitted line from this build? Please include the tested branch commit/base and whether those new lines identify any producer or only earlier stores. That should clarify whether these waits are rejected at submission or later overwritten; I’m not proposing a wait-semantic change from the current evidence.
7. dantdmdarealguy commented on Oct 22, 2026

   

   dantdmdarealguy

   on Oct 22, 2026

   Contributor

   More actions

   Stray (PPSA02100) 01.002.000 on current main d6eafa54d, Windows 11 Pro, Intel Core i9-14900K, NVIDIA GeForce RTX 5080 (driver 32.0.16.1742), Release, relinker --windows, APS5_PLAYGO_UNLISTED_CHUNKS=installed.

   The Stray row's signature still occurs, but rarely and without stopping the title: 8 timeouts in 1 of 18 runs (the first run, cold shader cache), 0 in the other 17 (60-900 s each, one of them cold again). In that run the title kept presenting after every timeout and reached the menu and controllable gameplay. The FATAL that followed the timeout in the 12 October row did not occur.

   [gpu] queue 0x20 WAIT_REG_MEM at 0x102103dc20 timed out after 1000ms (function 3 ref 0x1 mask 0xffffffff value 0x2103dc00)
   [gpu]   recorder: table miss (refusal 0), open batch writes it 0, snapshot write overlaps 0, pending completion labels 0, write-back completions 0, pending label age -1.0 ms, write generation 1946 seen 1946, queue 0 dormant 0, completions pending 0, label due 0
   [gpu]   preceding packet SET_SH_REG 00000240 20432600 c4700000 000fc00f a1b00fac 0000003f 00700000 006b0000
   [gpu]   preceding packet RELEASE_MEM 06000528 60010000 0ae8fe48 00000020 00000000 00000000 00000000
   [gpu]   preceding packet RELEASE_MEM 06000528 60010000 0ae8fdf8 00000020 00000000 00000000 00000000
   [gpu]   preceding packet SET_UCONFIG_REG 00000342 c8010010 2103dc20
   [gpu]   preceding packet WAIT_REG_MEM 00000013 2103dc20 00000010 00000001 ffffffff 00000019
   

   The other seven waited labels held 0x21041ca0, 0x210037a0, 0x20fae620, 0x20f99940, 0x2105c980, 0x2105f0e0 and 0x21048c20. The first and last are a label's own address ±0x20 or ±0x180; the others point further away in the same 0x1020f.....-0x10210..... area. The preceding packets have the same shape as the Coral Island row (SET_SH_REG 0x240 with a ... a1b00fac ... T#, two RELEASE_MEM to other addresses, SET_UCONFIG_REG 0x342, WAIT_REG_MEM 0x13).

   Label addresses repeat across Stray runs, so APS5_TRACE_LABEL=102103dc20 (with APS5_PM4_RING=256 APS5_STALL_WATCHDOG_SECS=2 APS5_LOG_SYNC=1) picks up the same slots in a later run. In those runs (7 warm 60 s runs and one 420 s cold run) no wait timed out. The trace shows the slot pool at a 0x20 stride (0x102103db40, ...db60, ..., ...dc20). On it, queue 0 writes each slot with DMA_DATA c6306000 00000000 00000000 <slot> 00000010 00000004 followed by RELEASE_MEM 0600e52d 20010000 <slot> 00000010 00000001, and then waits on it itself (WAIT_REG_MEM 00000113). Queue 0x20 waits on the same slots (WAIT_REG_MEM 00000013) and also produces some itself (DMA_DATA 46306000 ..., RELEASE_MEM 0600c528 ...). In the cold 420 s run, the 7 queue 0x20 waits in the traced window were all received before queue 0's DMA_DATA+RELEASE_MEM for that slot, 140-249 ms (median 173 ms) earlier, and all completed. A slot whose producer comes 140-249 ms after the wait is close to the 1000 ms timeout once a cold start slows queue 0 down. That fits the timeouts showing up only in the cold first run, but I have not traced a run that timed out, so this is not established.

   Not shown: what writes the address-like value into the slot (it looks like a free-list link from the CPU, but no CPU store was traced), and whether the wait in the timed-out run was received before or after its slot's last RELEASE_MEM. No change proposed.