Avalon 1166 Pro – BOOTBY 0x10 Reboot Loop

Confirm the code. Log into the miner's web UI at its LAN IP, open the background log (sometimes labelled `Miner Log` or `System Log`), and scroll to the most recent restart. You're looking for a line containing `BOOTBY[0x10.xxxxxxxx]` — the hex prefix is the diagnostic that locks you onto this page rather than one of the other BOOTBY variants (`0x02` overheat, `0x03` network, `0x11` no-hashrate, `0x21` soft reboot). Screenshot the exact line before you touch anything else — you'll need the full `0x10.xxxxxxxx` suffix to match against Canaan release notes.

Read the MM firmware version via API. `telnet <miner-ip> 4028` then send `{"command":"version"}` and press Enter. The reply includes `MM Version=` followed by a date-stamped build string such as `22061301_be77c30_ef5defc`. Record this exactly. If it's `22061301` (or a newer build that shipped between the `22061301` regression and its fix), you are almost certainly on the known-bad firmware that produces `BOOTBY[0x10]` on 1166 Pro MM313. If it's older, or on a release that Canaan specifically flagged as fixed, the root cause is likely elsewhere and you should work through Steps 6-9.

Pull a hashboard temperature baseline before touching firmware. `telnet <miner-ip> 4028` then `{"command":"estats"}`. Parse `PVT_T0`, `PVT_T1`, `PVT_T2` for each hashboard. Healthy 1166 Pro runs most chips under 75 C at nameplate. If you see sustained `PVT_T > 80 C` on one board, or `some chips reach Tmax more than 85C` in the log, the `0x10` reboot is being secondary-triggered by a thermal watchdog the MM firmware isn't labelling correctly. Force fans to 90% for diagnostic breathing room: `{"command":"ascset","parameter":"0,fan-spd,90"}`. Reboot interval should lengthen; if it disappears entirely you've got a thermal-plus-firmware stack, not pure firmware.

Check ambient + airflow. Measure intake temperature with an IR thermometer 10 cm from the front grille — not in the room, not in the rack, at the miner. Target ≤ 30 C. Confirm nothing is blocking intake (rack-neighbour exhausts, filters clogged with dust, a curtain, a box). On a 1166 Pro pulling 3.4 kW wall, intake restriction alone can walk `PVT_T` up 5-10 C over a day. If intake is clean and ambient is fine, the thermal excursion reported in Step 3 is being produced by the miner's internal response to the bad firmware, not the environment.

Download the last-known-good MM firmware. For the 1166 Pro BOOTBY 0x10 regression, the field-confirmed fix is downgrading to `22033101_4ec6bb0_49ce84a`. Canaan hosts firmware at `avalonminer.org/firmware-document/` and the login-gated `support.canaan.io` portal. If the target build isn't on the public page, open a support ticket at `avalonsupport@canaan.io` requesting the specific date-stamped build — Canaan has historically released older stable builds on request. D-Central's own [step-by-step Avalonminer firmware upgrade guide](https://d-central.tech/troubleshooting/step-by-step-guide-to-upgrading-avalonminer-firmware/) documents the flash procedure. Verify the image checksum against Canaan's published SHA before you flash — wrong image on a 1166 Pro bricks the MM313 fast.

Flash the downgrade via AUC3. Connect the AUC3 controller to the miner and to your workstation via USB. Use the cgminer web-UI upload flow or Canaan's official upgrade tool to push the `22033101` image. Wait for the full cycle to complete — do NOT interrupt mid-flash, do NOT pull USB, do NOT power-cycle until the miner fully reboots itself and the web UI responds again. A mid-flash power cut on MM313 is exactly how you turn a reboot loop into a doorstop. Once the miner comes back up, re-query `{"command":"version"}` and confirm the build string is now `22033101_4ec6bb0_49ce84a`.

Soak-test for 24 hours. Let the miner hash at stock profile. Tail the background log and grep for any `BOOTBY` line. On a successful downgrade you should see zero new `BOOTBY[0x10]` events within 24 hours — that's the bitcointalk-confirmed signature of this regression clearing. If you see `BOOTBY[0x02]` instead, your problem is actually thermal (the documented overheat code); jump to the Avalon temperature-too-high page. If `BOOTBY[0x10]` returns on the older firmware, you're in Tier 3 territory — the firmware is a contributing factor but not the whole story, and the hardware path needs bench-level isolation.

Re-seat the AUC3-to-miner USB and power connectors. Power off at the PDU. Unplug the AUC3 USB cable from both ends and inspect the pins for oxidation, pin walk, or bent contacts. Reseat every hashboard data ribbon and power connector on the MM313 — listen for the click. Re-apply dielectric grease sparingly on the AUC3 USB if your environment is damp (Canadian basements in spring). A flaky AUC3 link can produce pseudo-random BOOTBY events that sit right next to `0x10` in the log because the MM watchdog can't tell 'lost USB handshake' from 'firmware soft-reset'.

Refresh thermal interface material on the worst hashboard. Power off, open the miner, remove the top fan shroud, unscrew the hashboard with the highest baseline `PVT_T`. Carefully lift it — do NOT twist — to avoid cracking the edge connector. Clean old thermal pads from the ASIC side with isopropyl alcohol 99% and a plastic scraper. Apply fresh thermal pads (Arctic TP-3 or equivalent, ~1.5 mm pad thickness matched to the original). Reseat the hashboard, reconnect, close. On a 3-year-old 1166 Pro this step alone can shave 8-12 C off `PVT_T` under load and knock out thermal-adjacent BOOTBY events permanently.

Swap the PSU for a known-good Avalon-compatible unit. 1166 Pro pulls 3.4 kW — any APW-class PSU that is sagging under sustained load can trip the MM watchdog in ways that log as `BOOTBY[0x10]` rather than the documented `0x02` overheat. Meter PSU output at the board connector while the miner is hashing at full power — expect the Avalon DC bus to hold its rated voltage under load. If it sags, swap the PSU. Canaan's `shop.canaan.io` carries compatible replacements; D-Central stocks refurbished APW-equivalents for Avalon-class miners.

Soft-reboot via API after each change. `{"command":"ascset","parameter":"0,reboot,0"}` issues a clean MM-level reboot. Watch the log: a successful post-fix boot will show `BOOTBY[0x05]` (API reboot) — which is what you want to see — followed by clean `MM_STATUS` transitions and no `0x10` events for the next 24 hours. If you see `BOOTBY[0x05]` followed by `BOOTBY[0x10]` within the hour, your fix didn't hold and you need to go deeper.

If the downgrade fix doesn't hold, stop DIY and ship to D-Central. Persistent `BOOTBY[0x10]` across two firmware builds, visible damage on the MM313 or AUC3, hashboard `PVT_T` above 85 C with fresh thermal pads, or an AUC3 that won't enumerate puts you in test-fixture territory. We run MM313 under a programmable load on the bench, isolate AUC3 / hashboard / control-board failures with official Canaan diagnostic binaries, replace MM313 / AUC3 modules from stocked inventory, and re-flash the full firmware stack end-to-end. Book a slot at [d-central.tech/services/asic-repair/](https://d-central.tech/services/asic-repair/). 3-7 business days, Canadian workshop, ships Canada / US / international.

Preserve the forensic data when you ship. Before packing, export the miner's background log (full file, not a screenshot), record the exact MM firmware build string from `{"command":"version"}`, screenshot the `{"command":"estats"}` output showing per-hashboard `PVT_T`, and note the reboot cadence (every N minutes at ambient X C). Put all of that in a note with the shipment. Our bench technicians halve diagnostic time when they get forensic context, and that halves your repair invoice. Pack the miner in original foam if you have it; otherwise double-box with ≥5 cm of foam on every side, hashboards secure, AUC3 wrapped separately in anti-static.

After repair or fix, pin the firmware. Do NOT auto-update MM firmware on a 1166 Pro once you've found a build that holds stable. Canaan's firmware portal does not publish changelogs; every new build is a coin flip for regressions like `BOOTBY[0x10]`. Record the working build string and refuse the next 'required' update until an authoritative community source (bitcointalk thread, Canaan support ticket response, or D-Central's own testing) confirms the new build doesn't re-introduce 0x10 on MM313. Mining Hacker rule: don't flash what's working.

Set up proactive monitoring for the next one. Scrape the miner's background log via `cgminer-api` once a minute from your monitoring rig (Telegraf + InfluxDB, Awesome Miner, or a bash script hitting port 4028). Alert on any `BOOTBY[0x0X]` line that isn't `0x05` (API-requested reboot). A `0x10` that returns after months of clean operation is an early warning — usually firmware drift or thermal pad aging — that gives you days to respond before the miner starts losing serious revenue to the reboot storm.