diff --git a/harness/mame/NETWORK_REPORT.md b/harness/mame/NETWORK_REPORT.md index 90d282b..130c789 100644 --- a/harness/mame/NETWORK_REPORT.md +++ b/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) diff --git a/harness/udpstream/vtcmd.py b/harness/udpstream/vtcmd.py index 39462ff..8d8a4df 100644 --- a/harness/udpstream/vtcmd.py +++ b/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.")