Passer au contenu

Nous améliorons nos opérations pour mieux vous servir. Les commandes sont expédiées normalement depuis Laval, QC. Questions? Contactez-nous

Bitcoin accepté au paiement  |  Expédié depuis Laval, QC, Canada  |  Soutien expert depuis 2016

A1466_OT_REBOOT (BOOTBY[0x02]) Critical

Avalon 1466 – BOOTBY Overheat Reboot

AvalonMiner A1466 trips OVER_TEMP / OT1 / OT2 / OT3 (PS error bits 2/4/8) and the MM3v2 firmware writes BOOTBY[0x02.xxxxxxxx] to NVS on reboot. Without a cooling fix the loop reasserts every 20-90 minutes under load - same room, same dust, same trip. 0x02 is Canaan's documented overheat reboot code in Zeus Mining and Thanos Mining BOOTBY references; on the 1466 the dominant root causes are dust-loaded heatsinks, ambient envelope, fan degradation, dried thermal interface, or PSU thermal sensor.

Critical — Immediate action required

Affected Models: AvalonMiner A1466 - approximately 150 TH/s nameplate, A3207-class A14-generation ASICs (114 chips total, 38 per hashboard), MM3v2 control board, four DF1205012B2 (Martech) / cross-compatible HA1250H12SB-Z 120 mm fans, approximately 3230-3420 W wall draw at stock. Shares fan part, PSU family, and MM3v2 platform with Avalon 1346, 1366, 1446, and 1566 - many Tier 2/3 fixes apply across that generation. Do NOT cross PSU with 1166 Pro / 1246 - different generation, not electrically compatible.

Symptoms

  • Web dashboard reads Miner Status: Fault with OVER_TEMP, OT1, OT2, or OT3 in the status line, then reboots within a minute
  • Background log (web UI Miner Log / System Log, or cgminer-api estats) shows BOOTBY[0x02.xxxxxxxx] on the prior-boot line
  • Reboot cadence repeats - every 20-90 minutes under sustained load, or within minutes of restart on a warm-room day
  • kern.log or /var/log/cgminer.log contains over_temp, PS err 2, PS err 4, or PS err 8 lines preceding each reboot
  • Front-panel LED flips solid green to sustained red, fans ramp to 100% briefly, then the miner drops compute and parks
  • cgminer-api estats returns PVT_T[] with at least one entry at 95 C or higher on the affected chain just before the trip
  • MM_STATUS reads WORK_MODE FAULT, SYSTEMSTATU shows at least one chain in Error
  • Hashrate drops from nameplate ~150 TH/s to 0 TH/s until the auto-reboot completes; ~90-120 seconds of mining time eaten per cycle
  • Pool dashboard shows rhythmic offline / online transitions matching the reboot cadence
  • Intake temperature measured at the front grille reads above 30 C, or above 35 C past Canaan's absolute maximum
  • Heatsinks visibly dust-coated or daylight is no longer visible through the fin pack
  • At least one of the four DF1205012B2 / HA1250H12SB-Z 120 mm fans reports below 3000 RPM at full tach, or one fan stopped
  • Fault recurs at a predictable time of day (late afternoon, after a neighbour's HVAC kicks on, summer garage warmup)
  • BOOTBY[0x02] is the dominant prefix across the last 10-20 reboots; mixed with 0x10/0x11/0x12 indicates stacked faults

Step-by-Step Fix

1

Pull the power cord at the PDU, wait 60 seconds for bulk capacitors to drain, then restart. A full cold-boot clears any wedged MM3v2 state around the OVER_TEMP trip flag - Canaan's firmware occasionally holds the fault byte across a soft reboot. Count to 60; do not just hit the dashboard restart. This alone clears roughly one in five A1466 events that saw a transient thermal spike (warm intake air, an appliance on a shared HVAC circuit, an afternoon heat soak). If the miner runs an hour without re-tripping BOOTBY[0x02], you caught a transient and you are done. If it re-trips within minutes, escalate to Tier 2.

2

Vacuum the front intake grille and rear exhaust vent with a shop-vac using the soft-brush attachment. Pay attention to the four fan blades and heatsink fin packs visible through the grille. Dust-packed fins can raise heatsink-to-ambient delta by 8-15 C, which is the entire margin between running fine and OT on a warm day. No hard nozzle - you are moving dust, not polishing chassis steel. Restart and run for one hour. Clean intake alone resolves a large fraction of BOOTBY[0x02] events on a 1466.

3

Measure intake-air temperature with an IR thermometer held 5 cm from the front grille during hashing. Target 30 C or below for a Canadian basement or garage; 35 C is Canaan's absolute maximum per spec. If intake reads above 30 C, open a window, crack the garage door, or move the miner's intake to a cooler corner before doing anything more invasive. You cannot fix an ambient-envelope problem at the miner - the miner is just reporting what the room is doing to it.

4

Confirm physical clearance: at least 30 cm in front of the intake, at least 15 cm behind the exhaust. An A1466 piled on a shelf with no breathing room recirculates its own exhaust - which is exactly how a miner that ran fine last week starts throwing BOOTBY[0x02] this week after someone stacked a box in front of it. Pull everything back from the miner. Restart and confirm the fault does not return within an hour. In a multi-miner shed, reconfirm airflow direction - miners pointed at each other's intakes cook each other.

5

From the dashboard or telnet to port 4028, run {"command":"ascset","parameter":"0,fan-spd,90"} to force fans to 90% PID. Reboot interval should lengthen significantly - sometimes the fault disappears entirely. This is diagnostic, not a permanent fix: 1466 fans wear out within months at sustained max RPM. If the fault clears on forced 90%, you have isolated the thermal component and the underlying cause is dust, paste, or a marginal fan. Restore fan PID to default after diagnosis and proceed to Tier 2.

6

Open the chassis, remove each of the four A1466 fans in turn, and spin each by hand. A healthy dual-ball-bearing fan spins freely for 2-3 seconds after a flick. A failing fan grinds, buzzes, or stops immediately. Replace any fan that fails this test with a DF1205012B2 (current Martech revision used across A1326/A1346/A1366/A1446/A1466/A15) - cross-compatible with the older HA1250H12SB-Z on mounting and electrical. One spare SKU covers the entire A13/A14/A15 generation. Stock at least two spares per miner in production.

7

Measure the 12 V fan rail at the PSU-to-MM3v2 connector under load. Multimeter on DC, probe at the connector while the miner is hashing at full power. Expect 11.8 V to 12.2 V sustained. Below 11.6 V means a tired PSU sagging the fan rail - the fans slow, chips heat, the miner trips BOOTBY[0x02], and you chase a thermal fault that is actually a power fault. Swap to a known-good PSU from the 1346/1366/1446/1466/1566 PSU family. Do NOT swap in a 1166 Pro or 1246 PSU - different generation, not cross-compatible with A14 control signaling.

8

Re-torque the heatsink mounting clips on each of the three hashboards. A1466 heatsink clips loosen over 12-18 months of thermal cycling. A heatsink with even 0.1 mm of lift loses its paste contact patch and the chip beneath cooks while neighbours are fine. Remove heatsink, wipe old paste with 99% IPA, apply a thin uniform layer of Arctic MX-6 or Thermal Grizzly Kryonaut, reseat with even clip pressure. One hashboard at a time - do not mix clips between boards. Highest-leverage Tier 2 step on a 1466 with one chain dominating PVT_T[].

9

Install a foam pre-filter on the intake if your install does not already have one. D-Central strongly recommends a simple foam pre-filter on every A1466 install - catches dust before it hits the heatsinks and can be vacuumed or washed in seconds instead of opening the chassis. Without a pre-filter you rely on the heatsink fins themselves to catch debris, which is the exact failure mode Step 2 fixes - and you will be fixing it over and over. 30 PPI open-cell foam, cut to fit, replaced or washed every 30 days in dusty installs.

10

Verify line voltage at the outlet under load. On 240 V split-phase (correct feed for an A1466's 3230-3420 W draw) expect 235-245 V. On 208 V commercial expect 202-212 V. Low line voltage forces the PSU to draw more current, heats PSU internals, and can trip the PSU thermal sensor independently of hashboard sensors - which the firmware logs as BOOTBY[0x02] even though the chips are fine. Fix the feed before continuing - electrician or panel problem before miner problem. Never run an A1466 on 120 V.

11

Snapshot cgminer-api estats output to a text file before any further changes. Run echo -n '{"command":"estats"}' | nc 127.0.0.1 4028 from the miner or a network-connected laptop. Save as a1466-pre-tier3.txt. Capture the BOOTBY history from the background log too. If the miner ships to D-Central, that pre-fix snapshot is exactly what the bench tech needs - and it saves diagnostic time, which saves you repair dollars. Take photos of every step in the disassembly.

12

Remove the suspect hashboard, strip the heatsinks, and reapply thermal paste on every ASIC on the chain that dominated your PVT_T outlier list. Arctic MX-6 or Thermal Grizzly Kryonaut in a thin uniform layer - the grain-of-rice heuristic is for CPUs, not a multi-chip hashboard; you want a uniform film across each chip top. Replace any thermal pad under the PCH or voltage-domain ICs if pads are crumbled, discoloured, or compressed. Budget one hour per hashboard the first time, 30 minutes once practised. Where most BOOTBY[0x02] loops on miners 12+ months old finally break.

13

If one specific chip position is the outlier and paste refresh did not resolve it, reflow that single chip. Preheat the hashboard from below at 150 C for 3 minutes, hot-air from above at 310-330 C for approximately 30 seconds with flux around the chip periphery, natural cool-down. The A3207-class BGA tolerates a single reflow cycle reliably. A second reflow on the same chip within 90 days rarely sticks - at that point the chip is dying and needs graded-replacement. Practice on a junker board first if this is your first BGA reflow.

14

Reseat the MM3v2 ribbon connectors on all three hashboards. The IDC-style ribbons used on the 1166 Pro and 1246 carry over on the A1466 and oxidize the same way in humid environments. Pull each ribbon fully, wipe contacts with 99% IPA on a lint-free wipe, reseat until the latch clicks. Oxidized ribbons can break the temperature telemetry path specifically, causing one chain to appear cool while running hot - tripping BOOTBY[0x02] from the PSU thermal sensor while the chip telemetry says everything is fine.

15

Flash a known-good MM3v2 firmware build for the A1466 from Canaan's login-gated firmware portal at avalonminer.org/firmware-document/. Release notes are sparse, but it is the only official source. Verify your hardware revision against the firmware compatibility table before flashing - the wrong MM3v2 build for a late-rev A1466 can brick the control board. Flash via the dashboard's firmware page over a wired connection; never flash over wireless, never flash while hashing, never flash while an OT fault is active. Do NOT treat firmware refresh as the first move on BOOTBY[0x02].

16

Stop DIY and ship to D-Central when: every fan replaced, every heatsink cleaned, every chip repasted and the miner still trips BOOTBY[0x02] within 24 hours; reflowed a chip once and OT returned within 30 days; PVT_T[] returns impossible values (negative, above 200 C, or identical across all chip positions); same chip position trips on two different A1466 units in your rig; visible discoloration, burnt smell, or capacitor damage anywhere on the hashboard, MM3v2, or near the PSU. Book a slot at d-central.tech/services/asic-repair/. Turnaround 5-10 business days, Canada-wide, US and international welcomed.

17

What D-Central does at the bench: MM3v2 under a programmable load, per-chain isolation with Canaan diagnostic binaries, hashboard test fixture for the A3207-class BGA, chip-level replacement from salvaged-grade A14-generation inventory, full reflow + reseal, MM3v2 thermal-sensor trace repair where applicable, post-repair 24-hour burn-in at nameplate. Immersion conversion is a Tier 4+ option for A1466 operators chasing the absolute thermal envelope - talk to D-Central about whether your specific install pattern justifies the swap.

18

Pack for shipping. Pack each hashboard in anti-static bags, pack the MM3v2 separately, double-box with at least 5 cm of foam on every side. Include a printed diagnostic note with: the kern.log excerpt (actual OT lines and BOOTBY[0x02] byte), MM3v2 firmware build, PSU model, measured line voltage, intake ambient at trip, fan tach readings before failure, every Tier 1-3 step you have already run with results. Better notes, faster and cheaper repair. Never ship hashboards loose or in single-box packaging; A3207-class BGAs do not survive careless handling.

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.