# Ch302 closeout — syscall 0x13 HLE; channel-5 syscall sequence emerging

**Status:** Closed. **Verdict from re-running qbert.elf:**
`elf_first_unhandled_syscall (pc=0x00111D64 $v1=0x6B (=107))` —
qbert advanced 28,726 → **28,813 retires (+87)** through the paired
0x13 and into a THIRD syscall sharing the same channel-5 args.

## What landed

10th narrow $v0=0 case in the Ch273 dispatcher + 7th runner
observer (distinct-tuple tracking, paralleling 0x17). All
mechanical. Regression 177/177 (no new TB).

## The channel-5 syscall sequence (NEW structural finding)

The runner observers now show qbert running a **repeating
per-channel sequence**, not just isolated paired calls:

```
syscall_0x17 = count=2  args=(5, 0, -1, 0x00137568) distinct_tuples=1
syscall_0x13 = count=2  args=(5, 0, -1, 0x00137568) distinct_tuples=1
(next blocker) $v1=0x6B  args=(5, 0, -1, 0x00137568)
```

Three observations:

1. **0x17 and 0x13 are each now called TWICE** (count=2, up from
   count=1 in Ch301). When Ch301 HLE'd 0x17, qbert was blocked
   before its second 0x17 call. With 0x13 now HLE'd too, qbert
   loops back and makes both calls a second time — then hits 0x6B.

2. **All three syscalls (0x17, 0x13, 0x6B) share identical args**:
   `$a0=5` (channel id), `$a1=0`, `$a2=0xFFFFFFFF` (-1 sentinel),
   `$a3=0x00137568` (the per-channel ctx).

3. **This is a per-channel-resource sequence**, not a one-shot
   pair. qbert appears to be iterating: for each channel resource,
   it calls a sequence of kernel functions (0x17, 0x13, 0x6B, …)
   with the same channel id and context.

## Codex's pause-for-autopsy condition — assessment

Codex said: "if this clears and the next thing is a wait loop or
channel-5 event, pause for autopsy rather than adding more blind
success cases."

**The next blocker IS a channel-5 event** (0x6B with $a0=5). But
it is **not a wait loop** — it's a concrete unhandled syscall
(`elf_first_unhandled_syscall`, not `elf_timeout_with_hot_pc`).
qbert is making forward progress (+87 retires), not spinning.

**My read:** this is the boundary Codex flagged. The pattern has
shifted from "isolated syscall blockers" to "a repeating
channel-init sequence." Two paths for Ch303:

### Path A — continue mechanical (one more $v0=0 for 0x6B)

If 0x6B is just the third call in a finite per-channel init
sequence (e.g., the SDK does `SetX(ch); RegisterY(ch); EnableZ(ch)`
for each channel), then a few more mechanical $v0=0 cases will
clear the whole sequence and qbert moves on. Cheap to try; the
runner observers will show whether the sequence is finite.

### Path B — autopsy the sequence now

Disassemble the code region around PC 0x00111D64..0x00111DA0 (the
caller of these syscall wrappers) to understand the loop
structure. If it's `for (ch = 0..N) { syscall_0x17(ch); ... }`,
we learn N and the full syscall set up front, instead of
discovering them one trap at a time.

**Recommendation: Path B (brief autopsy) before Ch303.** The
triplet + count=2 pattern is strong evidence of a bounded loop.
A 20-minute disassembly of the caller would reveal:
- the loop bound (how many channels),
- the full syscall sequence per channel,
- whether any of these syscalls' return values are checked
  (which would make a blind $v0=0 wrong).

This matches Codex's instinct: stop adding blind success cases
once a *structured sequence* (not isolated calls) emerges. The
autopsy is cheap and prevents a string of one-trap-at-a-time
chapters.

## qbert progression

| Chapter | Blocker | retire_count |
|---|---|---|
| Post-Ch301 (0x17) | syscall $v1=0x13 | 28,726 |
| **Post-Ch302 (0x13)** | **syscall $v1=0x6B at 0x00111D64 (channel-5 args)** | **28,813 (+87)** |

## Files changed

- `rtl/ee/ee_core_stub.sv` — 1 new HLE case.
- `sim/tb/integration/tb_ee_core_syscall_hle.sv` — 0x13 subcase.
- `sim/tb/integration/tb_ee_core_elf_runner.sv` — 0x13 observer
  (distinct-tuple) + SUMMARY.

No new TB; regression unchanged at **177/177**.

## Ch303 framing — autopsy the channel-init sequence

Concrete first step for Codex/next chapter:

1. Disassemble 0x00111D40..0x00111DC0 (the wrappers + their
   caller). The syscall wrappers are likely 4-instruction stubs
   like 0x00110990 (the 0x7A wrapper from Ch294); the *caller* is
   what loops.
2. Identify the loop: is it `for each channel` or `for each
   resource`? What's the bound?
3. Enumerate the full syscall sequence per iteration (0x17, 0x13,
   0x6B, and whatever follows).
4. Decide: mechanical batch (add all the sequence's syscalls as
   $v0=0 at once) vs. modeling actual per-channel state.

The runner observer infrastructure (distinct-tuple tracking) is
already in place to validate whatever Ch303 decides.

## Regression

**177/177 PASS** (unchanged from Ch301; no new TB).