# Stage 1B round 3: USB02 mount failure and USB03 pass

Status: complete
Type: evidence
Updated: 2026-08-01
Next Action: none; retain as the historical failure round that led to the resolved USB02 incident

Project Map: work/maps/map-smi-firmware-stabilization-and-qualification.md
Workpackage: work/wp/completed/wp-restore-broad-usb-compatibility-baseline.md
Checklist: work/checklists/checklist-stage-1b-four-drive-usb-compatibility-baseline.md
Incident: work/incidents/incident-usb02-stage1b-post-open-session-failure.md

## Allocation and result

| Controller | USB drive | Result |
| --- | --- | --- |
| A / `1751136` | `USB02_8G` | FAIL: FileX application session closed after one clean reinsertion |
| B / `1751219` | `USB03_32G` | PASS: complete common workflow and independent Pi validation |

Both controllers ran the pinned Stage 1 Release S-record SHA-256
`713B60D7D5B58E55FB6979FCAAC5E0BE551E4ECA5D6D637EA06B4768F4E90655`.
Controller A retained SD CID `035344535330384780976F0084018559` and
Controller B retained SD CID `035344535330384780976F0085018507`; protocol,
CID-valid, representative-sector-read, and HPT-ready states remained valid.

## USB02 on Controller A

The first insertion reached USB attachment and a successful
`ux_system_host_storage_fx_media_get` result, but the FileX media identifier
remained zero. The handoff acceptance mask stayed `11`, so the application
correctly withheld the mounted state.

One permitted clean powered removal/reinsertion then reached acceptance mask
`15`, a valid `FX_MEDIA_ID`, and media generation `3`. The application session
subsequently closed while the device remained physically attached. Final
telemetry showed:

- `usb_mounted=0`, `device_attached=1`, and `port_status=1`;
- media-event status `0` and handoff status `0`;
- last handoff acceptance mask `15`;
- `usb_app_errors=1` and `system_errors=0`;
- pending storage instance `0` and effective FileX media pointer `0`.

The only application-error trap in this outer-thread transition is the
`fx_media_volume_get()` result. The exact FileX status is not retained by this
firmware, so the numeric failure remains unknown and must not be guessed. The
thread then flushes/closes the media and has no attached-device recovery path.
No second retry, VBUS diagnostic, controller power cycle, or drive-specific
mitigation was used.

Independent Pi inspection identified FAT UUID `D499-DF4E` and the expected
8,053,063,680-byte device. Read-only `fsck.fat -n -v` reached the final sector,
found a consistent filesystem, and left it unchanged. The only notice was the
pre-existing Windows root-label versus blank boot-label convention. The drive
contained only Windows metadata plus the original WAV files:

- `W00.wav`: 198,566 bytes, SHA-256
  `37A9DC665366F06D8081B23ECF88BDB30CF81546C3A10EDA1BE827DE2D006B92`;
- `W01.wav`: 176,516 bytes, SHA-256
  `E22FC8FFF2CF68878C56EA87660CA2325E0FBF04CF091AAEB112A7F274B1B2F7`.

No image, PID, CSV, `.tmp`, `.part`, or `.bak` file was present. The failed
session therefore produced no false-success artifact and did not damage the
filesystem.

## USB03 on Controller B

USB03 mounted on its first insertion at generation `3` with acceptance mask
`15`. WAV load, playback, PID capture, image publication, and retained HPT
export all completed with zero system or USB application errors.

- Image: 8,388,864 bytes in 8,193 writes, maximum 1,024 bytes, 394.08 seconds.
- First-publication FileX telemetry: one accepted `FX_NOT_FOUND` prior-image
  probe; terminal image result success.
- HPT request `3`: 61 degraded historical records, zero gaps, 3,739 bytes in
  four writes, maximum 1,024 bytes, complete and published.
- Final mounted state: generation `3`, acceptance mask `15`,
  `usb_app_errors=0`, `system_errors=0`.

Independent read-only Pi validation identified FAT UUID `BCE4-0E61`. The FAT
scan reached the final sector, found a consistent filesystem, and left it
unchanged apart from reporting the same known Windows label convention.

- Image SHA-256:
  `908966E3460C1594D21DE0B379BE2B06F1D51057A7EC5D1C25D0540F2381D7D9`.
- PID SHA-256:
  `6BCB89F2EFACC503B950EF00151A51AF8353C40B53781110C14DDC441737FC3A`.
- `R3B_USB03.csv`: 3,739 bytes, SHA-256
  `B4EADA5EE5CB6B504AB9F67CEC43340A596847CC0F8C101EBD2E900B0E915B40`,
  with `Export completion: COMPLETE; records published: 61`.
- Both WAV hashes matched USB02 and the prior rounds.
- No `.tmp`, `.part`, or `.bak` file was present.

The Pi kernel reported no reset, SCSI sense, medium, buffer-I/O, offline, or
block-I/O error for either drive. Both were left unmounted.

## Disposition

Round 3 fails the broad-compatibility gate because every selected drive must
work without specimen-specific treatment. USB03's pass remains valid evidence
but does not offset USB02's failure. Round 4 remains useful as a controlled
cross-controller diagnostic: USB03 on A and USB02 on B will show whether the
failure follows the specimen or the controller/session. Stage 2 remains
blocked.

## Raw evidence

- `work/evidence/hpt-log-store-circular-mirror/controller-a/stage1b-round3-usb02-20260731/`
- `work/evidence/hpt-log-store-circular-mirror/controller-b/stage1b-round3-usb03-20260731/`
