udpstream: the soft reboot has never worked (0/2) -- attempt 1 was a manual power cycle

The operator confirms attempt 1's recovery at 88 s was a manual power cycle,
not the payload.  That makes the record 0 confirmed successes out of 2, and
the first reading of attempt 1 -- "black and hung, needs a power cycle" --
was right after all.

Three corrections are now recorded in section 72.3, because they are one
mistake made three times: "hung" from a single sample, then "works" from the
same sample after it recovered, then "works" again when that recovery was
attributed to the payload.  The recovery had an external cause, which one
observation cannot tell apart from the payload working.

The Ghidra finding stands: the firmware has no software reboot, so there is
no supported entry to jump to.  Untested hypothesis for the hang remains
that the reset path leaves the LANCE busy-mastering; CSR0_STOP before the
jump would be the single-variable test.

vtcmd.py reboot requires --force and now says plainly that it has never
worked and that a power cycle should be expected.

harness/mame/NETWORK_REPORT.md

@@ -4693,50 +4693,50 @@ anyway, which is the condition we reproduce.
 MAME evidence: after the reply, the PC leaves the payload (`0x018Cxxxx`) for ROM
 (`0x3FB43E40` at the next sample) and the payload stops answering.
 
-### 72.3 On the real machine it succeeded once and hung the second time — it is NOT reliable
+### 72.3 On the real machine it has NEVER worked (0 for 2)
 
 Two attempts, both issued while the payload owned the LANCE, both acknowledged
 (`control -> bit 0x3f200040`, status 0), both followed by a screen that lost
-sync (the monitor went to sleep) rather than showing the power-on circle.
+sync — the monitor went to sleep rather than showing the power-on circle.
 
 | | attempt 1 | attempt 2 |
 |---|---|---|
 | time | 16:58:45 | 17:04:15 |
 | payload state | `RXF=11` | `RXF=15` (fresh power cycle before it) |
-| port 771 back | **yes, at 88 s** | **no**, still down at 130 s |
-| ping | yes | no |
-| display | Terminal Manager (VRAM screenshot) | monitor asleep, operator: "stuck" |
+| the payload's own effect | none observed | none observed |
+| recovery | **manual power cycle by the operator** | none; still down at 160 s |
+| port 771 | reopened 88 s later (that was the power-cycle boot) | never |
+| display | Terminal Manager after the manual cycle | monitor asleep |
 
-Attempt 1 looked like a working hand-back: 88 s later rdebug reopened, the unit
-answered ping, and the VRAM screenshot showed the Terminal Manager with
-`08-00-2B-16-4B-5A`, `100.103.100.103`, `LAT_08002B164B5A` and the clean-boot
-`Ethernet Port Error - 24` banner (section 65).
+**Attempt 1 was initially recorded here as a success**: port 771 reopened 88 s
+later, the unit pinged, and a VRAM screenshot showed the Terminal Manager — so
+the jump was credited with a working hand-back. The operator has since confirmed
+that the recovery was a **manual power cycle**, not the payload. 88 s is simply
+how long this machine takes to come up; our jump contributed nothing.
 
-**Attempt 2 never came back.** So the reset-vector jump is a **1-in-2** operation
-on this machine, and a power cycle is still required when it fails.
+So the honest result is **0 confirmed successes out of 2**, and the first reading
+of attempt 1 — "black and hung, needs a power cycle" — was right.
 
-**Hypothesis (untested).** The reset path does not reset the LANCE, and the
-payload hands over with the chip started and bus-master DMA enabled. If a
-transfer is in flight — or an interrupt is pending — when control jumps, the
-firmware's early board-window handshake (`0xC00000B0` / `0xC0000100` in the trace
-above) can wait forever, which would look exactly like this: dead display, no
-network, no progress. On the successful run the chip happened to be idle.
+Three corrections are recorded here on purpose, because they are all the same
+mistake and it was made three times: "hung" from one sample, then "works" from
+the same sample once it had recovered, then "works" again when the recovery was
+attributed to the payload. The recovery had an external cause (the operator),
+which a single observation cannot distinguish from the payload working.
 
-The single-variable experiment that would test it: `CSR0_STOP` (and mask
-interrupts) immediately before the jump, so the reset path starts with a quiet
-LANCE. That has **not** been run.
+**Hypothesis for the failure (untested).** The reset path does not reset the
+LANCE, and the payload hands over with the chip **started and bus-master DMA
+enabled**. If a transfer is in flight — or an interrupt is pending — when control
+jumps, the firmware's early board-window handshake (`0xC00000B0` / `0xC0000100`
+in the trace above) can wait forever, which is exactly what is seen: dead
+display, no network, no progress. The single-variable experiment would be
+`CSR0_STOP` (and masking interrupts) immediately before the jump so the reset
+path starts with a quiet chip. It has **not** been run.
 
-**Two corrections are recorded here on purpose.** First, an earlier reading of
-attempt 1 called it "black and hung, needs a power cycle", because the
-observation was taken inside the ~90 s window. Then, after attempt 1 returned,
-the opposite claim — "it works, no power cycle needed" — was made from the same
-single sample. Attempt 2 falsified that. Both mistakes are the same mistake rule 3
-of this project warns about: a conclusion drawn from one observation.
-
-`vtcmd.py reboot` therefore requires `--force` and states that it worked 1 of 2
-times. `jump` and `reboot` still transmit their reply and wait for the descriptor
-to complete before transferring control, so the host always gets its
-acknowledgement first.
+`vtcmd.py reboot` requires `--force`, states that it has never worked, and says
+a power cycle may be needed. `jump` and `reboot` still transmit their reply and
+wait for the descriptor to complete before transferring control, so the host
+always gets its acknowledgement first — which is why the failure is silent from
+the host's side.
 
 ### 72.4 There is no vendor reboot to jump to (checked in Ghidra)
 

harness/udpstream/vtcmd.py

@@ -194,11 +194,11 @@ def main():
     if a.cmd in ("jump", "reboot"):
         if a.cmd == "reboot" and not a.force:
             print("refusing reboot without --force.")
-            print("  It is NOT reliable: 1 success out of 2 attempts on the real")
-            print("  VT1200.  Attempt 1 came back in 88 s; attempt 2 never came")
-            print("  back (no ping, no rdebug, monitor asleep) and needed a power")
-            print("  cycle.  The screen always loses sync, so the monitor sleeps")
-            print("  for the whole window.  See NETWORK_REPORT.md 72.3.")
+            print("  It has NEVER worked on the real VT1200: 0 of 2 attempts.")
+            print("  Both ended with no ping, no rdebug and the monitor asleep;")
+            print("  the one time it appeared to recover, the operator had power")
+            print("  cycled the machine.  Expect to need a power cycle.")
+            print("  See NETWORK_REPORT.md 72.3.")
             return 2
         if a.cmd == "reboot":
             print("rebooting: it may take ~90 s and it may never come back.")