wall-2 session-82: counter-page PA hunt - the client's pagemap does not contain the counter pool (guest_pmap_win.py empty for 0x20400f000 and 0x121000000 ranges; semfix_uvmt's pin_counter_page never succeeded) and the vidmem-window hypothesis is not supported (poke_vidmem at the pool window offset 0x3F87000 + rank slots 0xfd0/0xfc0/0xfb0 with 6 then 0x40 changed the shadow but did not move the A8 wait); gdb attach hangs on the post-device spin (kill by PID + SIGCONT recovery)

1 files changed, 22 insertions, 0 deletions

diff --git a/tools/guest-diag/wall2/README-session77.md b/tools/guest-diag/wall2/README-session77.md
index 82e162b..891ef42 100644
--- a/tools/guest-diag/wall2/README-session77.md
+++ b/tools/guest-diag/wall2/README-session77.md
@@ -183,3 +183,25 @@
 * The rank slots for the GL client's channels (handles 0xbeec0100,
   0xbeec0104, 0xbeee0100 -> ranks 0,1,2): 0x20400ffd0 / 0x20400ffc0 /
   0x20400ffb0.
+
+## ADDENDUM (r686, session 82) — the counter-page PA hunt: pagemap route confirmed dead, vidmem-window hypothesis tested and not supported
+
+* The client's own pagemap does NOT contain the counter pool: the
+  semfix_uvmt tool's resolver (`guest_pmap_win.py <pid> 0x20400f000
+  0x204010000 64`) returns NOTHING, as does the UVM pool range
+  (`0x121000000 0x121100000`). The tool's `pin_counter_page` has
+  therefore never succeeded for these clients (the STALL WATCHDOG's
+  "re-pin counter" attempts across sessions produced no "counter:
+  pinned" line).
+* VIDMEM-window hypothesis tested: the counter VA 0x20400f000 is in the
+  emulated vidmem window (>= SVC_VIDMEM_VA_BASE 0x200080000), so its
+  window offset is 0x3F87000 (0x20400f000 - 0x200080000). The shadow
+  there is reachable and all-zero (`sema_vidmem_dump 0x3f87000,64`);
+  poking the rank slots (+0xfd0/+0xfc0/+0xfb0 = ranks 0/1/2) with 6 and
+  then 0x40 via `poke_vidmem` changed the shadow (verified by dump) but
+  did NOT move the client's wait. The vidmem route is not (or not only)
+  the completion path; the A8 loop's tables have another source.
+* gdb-attach hazard (again): attaches to the client in its post-device
+  spin hang with no output; two gdb chains had to be killed by PID
+  (never a pattern) and the client SIGCONT'd. Probe only while the
+  client is in do_poll.