# USB09 recovery-candidate Controller A failure

Status: complete
Type: evidence
Updated: 2026-08-01
Next Action: none; retain as historical failure evidence for the resolved USB09 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-usb09-false-write-failure-and-usb-compatibility-architecture-correction.md

## Pinned identities

- Controller A assembly `1751136`, J-Link `69664082`, hardware variant `0`.
- Release S-record SHA-256:
  `0FE12FCE02C411378D1AF45EB11C1AC27694A5D69613830FD970865518C72B3F`.
- Release ELF SHA-256:
  `FEABA960AFD9A55C4BE742C69974D9FE2369D99B20E663975AB5F320F78416FC`.
- Controller SD CID `035344535330384780976F0084018559`;
  detection state `5`, identity valid `1`, representative-sector read `1`,
  HPT state/status `5/0`, and replace-media `0`.
- USB09 pretest identity: label `USB09`, UUID `24E4-9846`, General UDisk
  serial `2512300955508200677718`, capacity 8,053,063,680 bytes.

## Initial USB session

USB09 mounted on first insertion. The initial capture showed USB mounted and
attached, configured host-port state, media generation `3`, handoff acceptance
mask `15`, application session state/status `2/0`, matching nonzero FileX media
pointer and media ID, pending instance `0`, system errors `0`, and USB
application errors `0`. No WAV or update files were expected on this incident
specimen.

## Full retained-range request

Request `2` targeted the complete retained range from HPT timestamp
`301739760` through `302268900` and output `USB09_RCV.csv`. The SD scan passed:

- 8,667 records scanned and 8,540 selected;
- all 8,540 selected records healthy;
- zero degraded records, snapshot gaps, requested-range gaps, or first failure
  sequence;
- scan complete in 11.06 seconds.

The USB publication then failed:

| Field | Result |
| --- | ---: |
| Export state / reason | `5 / 4` (failed / USB publication) |
| Published | `0` |
| Failure phase | `5` (`HPT_EXPORT_USB_PHASE_FILE_CLOSE`) |
| Raw FileX-call status | decimal `92`, raw `0x0000005C` |
| First failure status | decimal `92`, raw `0x0000005C` |
| Bytes requested | 99,328 |
| File writes / maximum | 97 / 1,024 bytes |
| File-write time | 70.69 seconds |
| File-close time | exactly 50.00 seconds |
| USB elapsed / total | 121.06 / 132.17 seconds |

After the authoritative failure, USB09 remained mounted and attached at media
generation `3`; the handoff and application session remained valid, pending
storage remained `0`, system errors remained `0`, and USB application errors
were `2`. No VBUS command, controller power cycle, reseat, optional
SYNCHRONIZE CACHE, STOP UNIT, remount, or specimen-specific behavior was used.

## Status correction

The prior USB09 request-2 and request-3 binary evidence also stores bytes
`5C 00 00 00`, while the JSON decoder prints the same value as decimal `92`.
The incident text incorrectly converted that decimal display to hexadecimal
`0x92` and associated it with `FX_ERROR_FIXED`. The observed raw value in all
three failures is `0x5C`; it is not the FileX constant `FX_ERROR_FIXED`
(`0x92`). The current failure is localized to the `fx_file_close()` return
path, but the origin and namespace of raw `0x5C` still require diagnosis.

## Disposition

USB09 fails the recovery-candidate Controller A gate and blocks Stage 1B and
Stage 2. Independent Pi inspection confirms differing FAT copies, an incorrect
free-cluster summary, no final file, and an incomplete 97,280-byte `HPTE.TMP`
ending mid-record without a completion marker. Evidence is in
`work/evidence/usb09-recovery-candidate-pi-failure-inspection-20260731.md`.
Do not retry, repair the evidence drive, or add a USB09-specific mitigation
before the close/driver failure is understood.

Raw captures remain under:

`work/evidence/hpt-log-store-circular-mirror/controller-a/usb-session-recovery-usb09-20260731/`
