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

CHAIN_FAIL Critical

Avalon 1246 – Hashboard Not Detected

hashboard not found - Avalon 1246 SYSTEMSTATU reports a hashboard Work: count less than 3, or the web UI returns Hash board value 1 or 2. The AUC3 controller cannot complete IIC enumeration on one or more of the three hashboards.

Critical — Immediate action required

Affected Models: Avalon 1246 (A3206M chip) | Avalon 1246 Pro | 1246 MaxSpeed bins

Symptoms

  • Dashboard hashrate sits near two-thirds of nameplate (stock 1246 running ~58 TH/s instead of ~90 TH/s, or 1246 Pro near ~60 TH/s of ~93 TH/s) for 30+ minutes of continuous mining
  • Avalon web UI Device tab shows `Hash Boards: 2` (or `1`) when all three are physically installed
  • `cgminer-api` `estats` response on port 4028 shows `SYSTEMSTATU[0] Work: 2` (or `1`) instead of `Work: 3`
  • `MW0` / `MW1` / `MW2` array for the missing chain is entirely zero, missing, or truncated from the API response
  • `ECHU[x x x]` reports non-zero bits on the affected chain position, or the slot's ECHU field is absent entirely
  • `PS[0]` bitmap shows a non-zero value, especially bits `512` (`OC_IOSA`), `1024` (`OC_IOSB`), or `2048` (`OC_IOSC`) flagging a PSU output-channel overcurrent trip upstream of the board
  • Top-panel status LED sits sustained red - the infamously ambiguous Avalon red LED covers seven distinct fault classes, see Mining Hacker Notes
  • Kernel log (`dmesg` over SSH, or `/tmp/log/log`) shows `avalon: chain X init fail`, `iic: no ACK from addr 0x60`, or `EEPROM read fail`
  • One of the three hashboard chassis fans runs at normal RPM but the corresponding board shows no thermal climb 30 seconds after boot (dead board = dead heat)
  • Pool side shows a normal stratum connection and stable share submissions - rejects are not climbing - because this is a detection problem, not a mining-quality problem
  • Re-powering the miner produces the fault consistently across reboots (intermittent = start at PSU and AUC3 cabling; consistent = start at the board itself)
  • Physical inspection of the missing board shows no obvious burn, but subtle discolouration or a dull brown haze around the 12V input pads or the PMIC cluster
  • Ambient intake temperature above 35 degrees C - some 1246 firmware revisions silently mask detection failures as thermal foldback

Step-by-Step Fix

1

TIER 1 - Hard power-cycle. Kill the PSU at the wall switch for a full 30 seconds to clear any wedged MM3v2 driver state from firmware updates or brown-out events. Do not just soft-reboot the web UI. Power back up and wait 3 minutes for full enumeration. Pull `estats` on port 4028 and check `SYSTEMSTATU`. If `Work: 3` returns, the controller was wedged and the hard cycle cleared it - log and monitor.

2

TIER 1 - Pull the cgminer API over TCP 4028. SSH in or use `netcat` from a workstation on the same LAN: `echo -n '{"command":"estats"}' | nc <miner_ip> 4028`. Expected healthy response: `SYSTEMSTATU` with `Work: 3`, `MW0/MW1/MW2` each returning 26 even data points above 3000, `ECHU` all zeros, `PS[0]` of 0. Identify which chain index (0/1/2) is missing - that is your target slot for Tier 2 physical work.

3

TIER 1 - Read `/tmp/log/log` over SSH. Grep for `chain`, `iic`, `EEPROM`, `OC_`, `UV_`, `PS`. `iic: no ACK from addr 0x60` means the MCU is dark on the bus. `EEPROM read fail` means the MCU is alive but its identity is corrupt - totally different branch leading to Step 13 EEPROM re-flash. `PS[0]=512/1024/2048` means the PSU tripped on that output channel; you are chasing the PSU, not the board.

4

TIER 1 - Check firmware version in the web UI against Canaan's latest signed release. If you are on a known-buggy build (rare but documented), note it before touching hardware. Canaan firmware is signed and rolls forward only; do not downgrade without first backing up every hashboard EEPROM file. Running outdated firmware on new silicon revisions is one path to enumeration failure.

5

TIER 2 - Full power-down and reseat the missing chain. Kill the PSU, wait 5 minutes for bulk caps to drain. Open the top cover. Unplug the signal ribbon on the dead chain, inspect both faces under light for oxidation, debris, or bent pins. IPA-swab both sides if the miner lives in a basement or garage. Reconnect firmly until the ribbon clicks. Loosen, clean, and re-torque the 12V DC lugs to 1.2-1.5 Nm (community consensus; Canaan publishes no spec). Close up, re-power, re-run Step 2. If the chain returns, log it - repeated reseat cycles on the same slot = failing connector, plan replacement.

6

TIER 2 - Slot swap. Move the suspect board to a different physical slot. Document which slot it came from and which slot it now occupies. Reboot, re-pull the API. If the fault moves with the board (new slot now shows missing) the board itself is bad - advance to Tier 3. If the fault stays with the original slot regardless of which board sits there, the problem is upstream: MM3v2 controller, backplane, or harness - advance to Step 8.

7

TIER 2 - Known-good board substitution. If you have a known-good 1246 hashboard (donor from a parts miner, bench stock, or a recently-repaired board), install it in the dead slot. Reboot, pull the API. If the known-good board enumerates clean, the original board is confirmed bad - Tier 3 territory. If the known-good board also fails to enumerate in that slot, the fault is fully upstream - PSU channel, backplane, or MM3v2 controller.

8

TIER 2 - PSU output verify under load. Power the miner back up. Under active mining load, measure 12V DC at the hashboard input lug with a multimeter (DC volts, common ground to chassis, red probe to the 12V lug). Expected: 12.0-13.2V steady at the input under full load. Below 11.5V, momentary dips to 0V, or a dead rail means the PSU's output channel tripped (`PS[0]` bits for `OC_IOSA/B/C`) or the lug is cold-jointed. Swap PSU channels between slots to isolate; if fault follows the channel, the PSU is done. Swap the whole PSU with a known-good 1246-compatible unit (not a 1166 PSU - they are not interchangeable) to confirm.

9

TIER 2 - Re-seat every ribbon / IIC harness across all three chains, not just the dead one. Intermittent IIC issues on one chain are often the leading edge of a harness or backplane problem that will spread to the others. Inspect for black oxidation, bent pins, cracked insulation along the ribbon, or signs of vibration wear. Replace any ribbon showing visible fatigue - aftermarket Avalon ribbons are cheap insurance.

10

TIER 2 - Measure line voltage at the panel under full mining load. On 240V split-phase expect 235-245V; on 208V commercial three-phase expect 202-212V. Low line voltage drives the PSU to pull more current, which drives rail droop on the output side, which cascades into `OC_IOSA/B/C` trips and `CHAIN_FAIL`. A 1246 on an undersized residential circuit is a classic 'CHAIN_FAIL every evening when the neighbourhood A/C kicks on' failure pattern.

11

TIER 3 - Tune the AUC3 IIC bus. In cgminer config (`/etc/cgminer.conf` or advanced UI settings), change `--avalon7-aucspeed` from the default `400000` to `300000`, and `--avalon7-aucxdelay` from `19200` to `24000`. Reboot. If the board re-enumerates and holds, you had a bus-timing issue, not a hardware fault - typical of long unshielded backplane runs or mixed-revision rigs. Permanently reduce the bus speed or replace the cable with a shorter, better-shielded run. The `avalon7` prefix still applies to A12 code - do not look for an `avalon10` flag, it does not exist in mainline.

12

TIER 3 - Measure hashboard domain voltages. Per the A1246 manual, normal hashboard voltage rail sits 1200-1320 mV and chip core voltage sits 290-350 mV. Probe the domain rail test points on the board with 12V applied via a bench PSU (or in-chassis with the miner running). Zero volts on either rail with 12V present at the input confirms a dead domain - PMIC, bulk cap short, or blown fuse. This is component-level rework territory.

13

TIER 3 - EEPROM re-flash via Canaan FMS tool. If Step 3 showed `EEPROM read fail` but no IIC nacks, the MCU is alive but its identity is corrupt. Zeus Mining documents the FMS procedure for Avalon A10/A11/A12 EEPROM re-flashing. You need the exact EEPROM file for your hashboard bin (standard/Pro/MaxSpeed) and hardware revision. Wrong file = permanently bricked board. If you do not have the matched EEPROM file on hand and verified against your board's label, stop and ship the board to a repair shop that does.

14

TIER 3 - Visual PMIC and MLCC inspection under magnification. Look for bulging or vented electrolytic bulk caps, cracked or shorted MLCC ceramic caps near the PMIC cluster, discolouration on the PMIC package itself, or a ring of brown haze around any component indicating sustained heat damage. Any of these findings moves you to Tier 4 - component-level replacement needs a reflow station, hot-air rework, and spare parts stock.

15

TIER 3 - DNS sanity. Default Canaan firmware ships with DNS `114.114.114.114` (Chinese public resolver). If your router cannot reach it, stratum and firmware update lookups fail silently and can mask diagnostics. Change to `8.8.8.8`, `1.1.1.1`, or your own resolver in the web UI network settings. This will not fix a hardware `CHAIN_FAIL` but it removes a class of false-positive 'miner acting dead' reports from your troubleshooting scope.

16

TIER 4 - Stop DIY and ship the board. Triggers: per-slot fault is position-locked without a donor MM3v2 on the shelf; PSU drooping on multiple channels; confirmed dead MCU on bench fixture; visible burn or PMIC damage; bricked EEPROM without a matched re-flash file; batch-level failure pattern across multiple units in your fleet. Book a D-Central repair slot at d-central.tech/asic-repair-center. Ship the hashboard (or the whole miner) with a written note covering observed symptoms, firmware version, `estats` output at time of failure, and your contact details.

17

TIER 4 - D-Central bench process. Incoming board is cleaned, visually inspected under magnification, bench-powered with clean 12V and tested against a known-good AUC3 fixture. `estats` pulled at every stage. Component-level repair covers PMIC replacement, bulk / MLCC cap swap, cold-joint rework, fuse replacement, and A3206M chip replacement from graded stock when required. EEPROM re-flashed via FMS tool with the correct file for the bin and revision. Full 24-hour burn-in at nameplate voltage and frequency on a verified 1246 PSU. Photos and fixed quote delivered before any work; customer approves before parts spend.

18

TIER 4 - Safe shipping back and forth. Pack the hashboard in an anti-static bag; double-box with at least 5 cm of foam on every side (ECCN-style packing). Remove the heatsink only if requested by D-Central. Include a written note with observed symptoms, firmware version, `estats` output text, your contact info, and any prior repair history on the board. Good packing and documentation save diagnostic time and directly save you money on the repair quote. Canada-wide, US, and international shipping all welcome; turnaround 5-10 business days from receipt.

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.