Avalon 1166 – Hashboard Not Detected
Your Avalon boots, the AUC3 controller blinks, and cgminer comes up — but one or more of the three hashboards simply isn't on the bus
Critical — Immediate action required
Symptoms
- Dashboard hashrate sits near **two-thirds of nameplate** (a 1166 running ~52 TH/s instead of ~78 TH/s, or ~55 of ~81 TH/s on the Pro) for 30+ minutes
- Avalon web UI **Device** tab shows `Hash Boards: 2` (or `1`) when all three are physically installed
- `cgminer-api` `estats` response shows `SYSTEMSTATU[0] Work: 2` instead of `3`
- `MW0` / `MW1` / `MW2` array for the missing chain is entirely zero or missing from the response
- `ECHU[x x x]` reports non-zero bits on the affected chain position, or the slot is simply absent
- The miner's **top-panel status LED** sits sustained red (the infamously ambiguous Avalon red LED — see Mining Hacker Notes)
- Kernel log (`dmesg` over SSH or `/tmp/log/log`) shows `avalon: chain X init fail` or `iic: no ACK from addr 0x`
- One of the three hashboard fans runs at normal RPM but its board shows **no thermal climb** 30 seconds after boot (dead board = dead heat)
- Pool side shows normal stratum connection but stale/rejected share count is stable — this is a detection problem, not a mining problem
- Re-powering the miner produces the fault **consistently** (intermittent = start at PSU and AUC3 cabling; consistent = start at the board)
- Physical inspection of the missing board shows no obvious burn, but a subtle discolouration around the 12V input pads or the top-side PMIC cluster
- Ambient in the mining room is above 35 degrees C at the intake — the 1166 will mask detection failures as thermal foldback in some firmware revisions
Step-by-Step Fix
Pull the API SSH into the miner (or use `netcat` from a workstation on the same LAN) and hit the cgminer API on port 4028: ``` echo -n '{"command":"estats"}' | nc <miner_ip> 4028 ``` Expected: `SYSTEMSTATU` shows `Work: 3`, `MW0/MW1/MW2` each contain 26 even data points above 3000, `ECHU` array is all zeros. If one of `MW0/MW1/MW2` is empty or `SYSTEMSTATU` work count is 2 or 1, you've confirmed the missing chain index. Note which one: this tells you which physical slot to open.
Read the log `cat /tmp/log/log` (or whatever path your MM3v2 revision uses). Search for `chain`, `iic`, `EEPROM`, `OC_`, `UV_`. If you see `iic: no ACK from addr 0x60` (or similar), the board is dark on the bus. If you see `EEPROM read fail`, the EEPROM is corrupt but the MCU is alive. Different branch.
Full power-down and reseat Kill the PSU at the switch. Wait 5 minutes for bulk caps to drain. Open the top cover, disconnect and reconnect the signal ribbon and the 12V lugs on the missing chain. Close up, re-power. Re-run Step 1. If the chain comes back, you're done — but log this: repeated reseat cycles = failing connector, plan replacement.
Slot swap Move the suspect board to another slot (document which physical slot it was in and which it's now in). Re-boot, re-run the API. If the fault moves with the board: the board is bad, skip to Tier 3. If the fault stays in the slot: MM3v2 / backplane / cable harness — skip to Step 6.
Known-good board test If you have a known-good 1166 hashboard (or a donor from a parts miner), install it in the dead slot. Does it come up? If yes, confirmed bad board — Tier 3. If no, confirmed controller-side — Step 6.
PSU output verify Under load, measure 12V at the hashboard input lug with a multimeter (DC, common ground to chassis). Expected: 12.0-13.2V steady. If you see droop below 11.5V or zero volts, the PSU output channel to that slot has tripped (`PS[0]` bits for `OC_IOSA/B/C` — 512/1024/2048) or the lug is cold-jointed. Swap PSU channels or the PSU itself.
AUC3 IIC bus sanity Try dropping `aucspeed` to 300000 and bumping `aucxdelay` to 24000 in the miner's cgminer config, then rebooting. If the board re-enumerates, it's a bus-timing / cable-quality issue, not a hardware failure. Long or unshielded backplane cables are the usual culprit. Permanently reduce the bus speed or replace the cable.
EEPROM recovery If the MCU is alive but the EEPROM is corrupt (Step 2 showed `EEPROM read fail`), a re-flash of the board's EEPROM file is possible using Canaan's FMS tool (Zeus Mining documents the procedure for Avalon A10/A11/A12). This is advanced — Tier 3. Wrong file = permanently bricked board.
Bench test the board If all of the above fail and you still have a suspect board, a bench PSU + AUC3 test fixture can validate the MCU in isolation. If the MCU won't boot on the bench with clean 12V and a known-good AUC3, the board is dead — component-level repair or replacement only.
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.