Avalon 1246 – Reboot BOOTBY Code Diagnosis
Info (diagnostic code — non-destructive on its own; the pattern tells you whether your 90T rig is dying or just restarted cleanly)
Informational — Monitor and address as needed
Symptoms
- Miner reboots itself on a repeating cadence (every N minutes, hours, or on load spikes) without the operator pressing anything
- The background log (web UI → `Miner Log` or `System Log`) shows one or more `BOOTBY[0xNN.xxxxxxxx]` lines — this page decodes every prefix
- Pool dashboard shows repeated `share dropouts` or `offline` transitions on a rhythmic interval — 5 min, 30 min, hourly
- `{"command":"version"}` on port 4028 returns a valid `MM Version` build string but the miner keeps restarting anyway — the firmware is live, the watchdog is firing
- `{"command":"estats"}` on port 4028 shows a recent `BOOTBY[0xNN]` field and `Elapsed` counter resetting every time the loop fires
- `BOOTBY[0x01]` — hard reboot or unknown reboot (power event, cold start, or unclassified)
- `BOOTBY[0x02]` — overheating-triggered reboot (some firmware renders as `0A1E`); frequently paired with `PVT_T` entries > 85 °C
- `BOOTBY[0x03]` — network problem (stratum drop, DNS timeout, bad pool response)
- `BOOTBY[0x04]` — network back-end reboot (firmware re-initialising stratum / API subsystem)
- `BOOTBY[0x05]` — API reboot (operator or controller issued `ascset 0,reboot,0`; healthy, non-destructive)
- `BOOTBY[0x11]` — no hashrate in 5 minutes (hashboard or ASIC failure, firmware gave up waiting)
- `BOOTBY[0x12]` — hashrate dropped below 70% of nameplate (degraded chip or thermal throttle)
- `BOOTBY[0x21]` — soft reboot (intentional MM restart, usually after a config change)
- `BOOTBY[0x10]` — **not** in Canaan's documented table; MM watchdog fired, cause unclassified. In the Avalon 1166 Pro ecosystem this code clustered around specific firmware regressions; on the 1246 it appears on aging MM firmware or under PSU sag at 3.4 kW load
- Fan PID ramps hard right before the reboot — a thermal component is almost always lurking underneath the log code, regardless of which prefix prints
Step-by-Step Fix
Confirm your exact `BOOTBY` prefix from the miner background log — screenshot the full `BOOTBY[0xNN.xxxxxxxx]` line.
Pull 10-20 recent reboot entries to establish the *pattern* (cadence, mixed vs single code).
Query `{"command":"version"}` on port 4028 to read the current MM firmware build string.
Query `{"command":"estats"}` to pull `PVT_T`, `DH%`, and `MM_STATUS` across all three hashboards.
Verify intake ambient ≤ 30 °C with an IR thermometer; clean filters if dusty.
Temporary workaround while diagnosing: `{"command":"ascset","parameter":"0,fan-spd,90"}` forces fans to 90% to buy thermal headroom.
Download Canaan's last-known-good MM firmware from `avalonminer.org/firmware-document/`; verify SHA.
Flash via AUC3 using Canaan's upgrade tool or D-Central's guide. Do NOT interrupt mid-flash.
Soak-test 24 hours — expect zero `BOOTBY[0x02]` or `BOOTBY[0x10]` if the firmware was the primary cause.
Reseat AUC3 USB + hashboard data ribbons if the pattern returns. Dielectric grease on oxidised USB pins.
Measure PSU rails under load at the board connector with a multimeter; swap the PSU if sagging below 12 V.
Refresh thermal pads on the hashboard with the highest baseline `PVT_T`. Arctic TP-3 or equivalent, 1.5 mm pad thickness matched to original. IPA 99% to clean old pads. An 8-12 °C drop in `PVT_T` is typical on a 3-year-old 1246 and resolves thermal-adjacent `BOOTBY[0x02]` / `0x10` events.
Inspect the MM control board and AUC3 for physical damage — scorched traces, bulging electrolytics on the hashboard LDOs, corroded USB pins. 1246s that ran 24/7 through two Canadian winters see enough thermal cycling to fatigue solder and dry electrolytics.
Test with a spare AUC3 if you have one. Canaan's `shop.canaan.io` stocks replacements; D-Central carries refurbished units for Avalon-class miners. AUC3 handshake glitches can produce `0x03` or `0x10` reboots that masquerade as firmware.
Ship to D-Central when: firmware refresh + hashboard reseat + PSU swap all fail, MM / AUC3 has visible damage, `PVT_T > 85 °C` persists after a full pad refresh, or the reboot cadence makes the miner economically unoperatable. [Book a slot](https://d-central.tech/services/asic-repair/). We run MM hardware under programmable load with Canaan's diagnostic binaries, replace MM / AUC3 modules from stocked inventory, and re-flash the full stack end-to-end. 3-7 business days, Canadian workshop, ships Canada / US / international.
After any repair or firmware fix, pin the build. Record the working `MM Version` and refuse the next update until an authoritative source (D-Central testing, bitcointalk thread, or a Canaan support-ticket response) confirms the new firmware doesn't re-introduce a `BOOTBY` regression. Mining Hacker rule: don't flash what's working.
When to Seek Professional Repair
If the steps above do not resolve the issue, or if you are not comfortable performing these repairs yourself, professional service is recommended. Attempting advanced repairs without proper equipment can cause further damage.
Related Error Codes
Still Having Issues?
Our team of Bitcoin Mining Hackers has been repairing ASIC miners since 2016. We have seen it all and fixed it all. Get a professional diagnosis.