Avalon 1266 – Fan Speed Error

Power down at the PDU and confirm the thermal state first. The A1266 will keep trying to hash with one fan down - a 3,500 W heat engine with 75% of its airflow. Don't let it. Kill power at the PDU (not the web UI, not the rocker switch on the PSU). Open the top cover within 2 minutes so residual heat dissipates before you start probing. A dead fan running even 10 extra minutes on a 1266 can bake thermal pads and cost months of hashboard life. This is the single most important step, and it is truly non-negotiable.

Read the log, write down the fan number. On the miner's web UI or via `estats` over the port-`4028` API, record exactly which fan position reports `0`. Is it `Fan1` (typically front-top intake per Canaan's harness convention, but confirm on *your* unit's silkscreen - revisions vary)? `Fan2`? All four? One fan per hashboard? The position dictates the repair - intake and exhaust are the same log line but different physical parts to order and different airflow implications. Screenshot or copy the full `estats` response. That artifact is the difference between a 20-minute fix and a 2-hour scavenger hunt.

Blow the suspect fan out with canned air. Upright can, short controlled bursts. Hold the blade still with a plastic probe while blasting - letting canned air spin the fan backward through the motor windings induces back-EMF that stresses a tired bearing further. Dust dams on the hub are a common cause of a fan that *looks* fine but reads `0 RPM`. If you've got a basement shop, a garage miner, or any pets within 50 metres, this step resolves the fault a meaningful fraction of the time on its own.

Check ambient at the intake with an IR thermometer or shop thermometer at the front grille - not in the middle of the room. The A1266's thermal governor assumes `≤35 °C` inlet per Canaan's operating spec (`-5 to 35 °C`). If your intake is sitting at 38 °C because it's July in Ontario, the fan controller may have the survivors pinned at `100%` duty cycle - that's what you're hearing, not a real `Fan_FAULT`. Confirm the `Fan[0]` reading against intake temp: if every fan reads real RPM except one, it's not ambient, it's the fan.

Reseat the fan connector at the MM3 board. Power off at the PDU, wait 60 s for caps to bleed, pop the top cover. Locate the 4-pin fan header on the MM3 matching the log's fan position. Unplug, inspect the shell for bent pins or a crushed plastic latch, reseat firmly until you feel the positive click. This single step fixes a large fraction of `Fan[0]` tickets D-Central sees on shipped-in Avalons. Before closing the lid, apply a trace of dielectric grease to the pins - vibration is what backed the connector out the first time and it will do it again without help.

Inspect the fan cable end-to-end. Look for: chafe points where the harness runs past sheet-metal edges in the 1266 chassis, strain-relief damage at the fan-side terminal, heat discoloration on the jacket, or crush damage from the top cover being reinstalled over a pinched cable. Replace the harness if anything looks off. The convention on 4-pin PWM fans in this class is `GND / +12 V / TACH / PWM`, but verify against the MM3 silkscreen on your specific board revision before assuming - Canaan has shuffled pinouts between MM2 and MM3 generations without publishing a clean changelog.

Swap the suspect fan into a known-good position on the same MM3. Four fan headers, four fans. Move the suspect fan's harness to a header you know works. Power on, re-read `estats`. If the suspect fan now spins and reads correctly in the new slot, you've isolated the fault to the *original slot* - a board-side problem (blown fuse, dead driver, cracked resistor). That's Tier 3/4 territory. If the suspect fan still reads `0` in a known-good slot, the fan itself is dead and needs replacement.

Measure +12 V rail at the dead fan header under load. Multimeter on DC volts, probe `V+` to `GND` on the MM3 fan header while the miner is powered on and the controller is commanded to spin. Expect `11.8 - 12.2 V` steady. Below `11 V` or reading nothing = a blown SMD fuse or a supply-rail fault on the MM3 - Tier 3. A healthy `12 V` rail with a still-dead fan means the fan or the harness is at fault - replace whichever you haven't already swapped.

Use `ascset|0,fan-spd,90` as a diagnostic. The bitcointalk community documented this command for the Avalon MM firmware family: `echo '[{"command":"ascset","parameter":"0,fan-spd,90"}]' | nc <miner-ip> 4028` ([source](https://bitcointalk.org/index.php?topic=5436344.0)). Try 20, 50, 90. A healthy fan responds within a second; a dead one does not. This is a *diagnostic*, not a fix - the manual override does not persist across reboots. Do not use it to mask a real failure; the thermal governor is there for a reason.

Check kernel log for `BOOTBY[0x10.<addr>]` overheat reboots. If you find repeated `BOOTBY[0x10.*]` entries, the fan failure has already caused overheat events - your three hashboards have been through thermal cycling they should not have. Plan a thermal-paste refresh at the next reasonable opportunity, and watch for elevated per-chip CRC errors over the following week. A 1266 that gets cooked once can limp for months before hidden silicon damage surfaces as `ASICCRC` faults.

Replace the fan with the correct part. Stock A1266: `YD12038B2G` or equivalent 12038-class fan - `12 V / 4.5 A / 120 x 120 x 38 mm / ~6000 RPM / 4-pin PWM / ball-bearing axial / ~210 CFM / ~64 dB(A)` per [Zeus Mining's YD12038B2G part sheet](https://www.zeusbtc.com/ASIC-Miner-Repair/Parts-Tools-Details.asp?ID=1232). The listed compatibility is `A1066 Pro / A1126 / A1146 / A1166 / A1246`; the 1266 shares the same chassis-fan geometry and MM3 harness, so the part fits. Do NOT substitute a 120 x 120 x 25 mm or x 38 mm *generic PC* fan - most consumer 120 mm fans top out at `~2000 RPM` and `50-70 CFM`, nowhere near the 1266's `210 CFM` at `6000 RPM` requirement. Thinner / slower fans cut airflow and you'll be back at the same diagnostic in two weeks. Confirm polarity against the MM3 silkscreen before power-on.

Replace the SMD fuse on the MM3 fan rail. If your voltage measurement in Step 8 showed the `+12 V` rail dead on one fan header while others were healthy, a Canaan-side SMD fuse popped when a previous fan seized and drew stall current. The fuse is typically a 1206-package fast-blow in the `5 - 10 A` range; identify by following the rail from the fan header back to the nearest SMD fuse on the board. Reflow the replacement with hot air at `290 °C` using Kapton tape to protect adjacent plastics. Verify rail voltage returns to `12 V` under a dummy load before reconnecting a real fan.

Firmware downgrade from a known-bad MM build. If Steps 1-12 haven't resolved and `estats` shows all four fans reporting `0` plus temperature sensors at `-273 °C`, you've hit a firmware-level failure. Pull the MM firmware version via `ascset|0,ver`. If you're on a build known to regress sensor polling (the `22061301_be77c30_ef5defc` class and its derivatives documented on bitcointalk for the A1166 Pro apply to the same MM3 firmware family that powers the 1266), downgrade to a last-known-good. Match the board's silkscreen rev to the firmware target; wrong rev bricks the controller and turns a Tier 3 job into a Tier 4 board swap.

Replace the MM3 control board. If the fan rail is dead and the SMD fuse swap didn't restore it, damage is deeper than a single component - gate driver, voltage regulator, or a board-level short. At that point, replacing the full MM3 is faster than component-level rework unless you have bench fixtures for the A1266. D-Central stocks pulled MM3 boards from decommissioned A1126 / A1146 / A1166 / A1246 / A1266 units - the control board is cross-compatible across that whole generation per Canaan's own part sheet ([Zeus](https://www.zeusbtc.com/ASIC-Miner-Repair/Parts-Tools-Details.asp?ID=1626)), so the inventory pool is deep.

Refresh thermal paste on all three hashboards if overheat events occurred. If the dead-fan state ran long enough to trigger `BOOTBY[0x10]` overheats, the thermal-interface material on the 1266's three hashboards took abuse. Pull each hashboard, replace paste on the ASIC-to-heatsink interface with Arctic MX-6 or Thermal Grizzly Kryonaut, inspect thermal pads between PMIC / PVT sensors and the chassis for crumbling. This is preventative work that pays off when you want to keep a 1266 alive through another halving.

Stop DIY when any of these are true: `+12 V` rail is dead across multiple fan positions (not just one), visible heat damage or discoloration on the MM3, two fans failed in the same rig within 30 days (points upstream - PSU, grounding, ambient excursion), any fan failure coinciding with a hashboard going dark or throwing `ASICCRC` errors, or you attempted SMD rework and lifted a pad. That's [D-Central Avalon repair bench](https://d-central.tech/services/asic-repair/) territory - not fan territory.

What D-Central does at the Avalon bench. Diagnosis against a known-good A1266 reference rig, MM3 component-level repair including SMD fuse and gate-driver replacement, fan harness remake with dielectric-greased connectors, full hashboard thermal service if overheat events occurred, and 24-hour nameplate burn-in (`100 TH/s / 3,500 W`) with all four fans monitored via continuous `estats` polling before we ship the unit back. The MM3 compatibility across the A11 / A12 generations means we can pull a verified-good control board from inventory in hours, not weeks.

Ship the whole miner, not the MM3 alone. The 1266's fan assembly is awkward to pack safely separated from the chassis. Double-box the full unit, remove the three hashboards and wrap separately in anti-static bags, include a note with your failing `estats` output, MM firmware version, and observed symptoms. That saves diagnostic hours on our side, which saves repair dollars on yours. Canadian customers can ship to our Quebec bench and have the miner back in a week.