Antminer Troubleshooting Decision Tree: Eight Symptom Doors

Every Antminer fault walks in through one of eight doors. This page is the switchboard: pick
the symptom you can actually observe, run the one decisive check that splits the cause space, and
follow the route to the specific fix guide — we maintain 650 error-code pages and 140 hands-on
troubleshooting guides behind these doors, so the deep content is one click away, not
restated here.

Before any board-level work: two of these doors fork on your control-board
family (Zynq, BeagleBone, Amlogic, CVitek) — recovery media and even which rails exist differ
per family, and one model can ship with four different boards. If you don’t know yours,
take sixty seconds with the
control board identifier first.

Pick your door

• 1. No power, no LEDs, nothing
• 2. Red light (solid or flashing)
• 3. Fans at full speed, no hashrate
• 4. “0 ASIC” / chain break in the log
• 5. Domain / voltage fault
• 6. Temperature-sensor errors
• 7. PSU suspected
• 8. Log signatures & firmware errors

Door 1 — No power, no LEDs

Decisive test: on 17- and 19-series all-in-one units, confirm BOTH AC cords are
seated — a single unplugged cord is the classic false “dead miner”
(field-corroborated, not Bible-verified). Then verify your line voltage: APW12 and APW17
supplies are 200–240 V only and will not start on 120 V. Still dead? Measure DC at
the PSU output with a multimeter: an APW7-class supply should hold 11.60–12.60 V; the
S19j Pro’s APW121215a runs ≈13.5 V on the shared rail (design range
11.96–15.20 V). You should see a stable in-range voltage — no voltage,
or voltage far out of range, means the fault is upstream of every board in the machine.

Route:

• The full isolation ladder: wall → PSU → control board → hashboards
• APW PSU not powering on
• 220V vs 110V — why the PSU won’t start
• Testing the PSU with a multimeter

Door 2 — Red light

First check: note the exact LED behavior — solid, alternating with green, or
flashing — and take it to our
red-light guide, which owns the pattern-by-pattern diagnosis end to end. One reassurance from
that guide before you open anything: a brief red flash during boot is normal POST behavior, not a
fault.

Route:

• Red light diagnosis and repair, end to end
• Solid red — error-code entry
• Red/green alternating — error-code entry
• Signal lights explained (all states)
• Red+green stuck during an SD flash? Rule out ANTBUILD-class malware

Door 3 — Fans at full speed, no hashrate

Decisive test: fans spinning prove exactly one thing — the control board has
power and booted far enough to drive them. Fans pinned at 100% with zero GH/s almost always means
the board booted but could not initialize the hash chains: the fan controller defaults to full
blast when chain init fails. Pull the chip count per chain (web UI, or
cat /sys/class/hwmon/*/chip_count over SSH) before assuming anything. A fan
error in the log — a tach fault, with hashing still attempted — is a different door
entirely.

Route:

• The dedicated diagnosis: chip counts, chain breaks, crystal, UART
• Green LED but not hashing
• Zero hashrate that recovers on reboot
• Different symptom: a FAN error (tach fault), not a hash fault

Door 4 — “0 ASIC” / chain break

Decisive test: count what the board actually detected. Over SSH:
cat /sys/class/hwmon/*/chip_count. You should see the full chip
count for your model on every chain. A chain that enumerates M of N chips breaks between chip M
and chip M+1 — that number is your map coordinate: a signal-path fault (dead chip, cold solder on
the clock/data forwarding pins, or a failed level shifter at a domain boundary), not a firmware
problem.

Route:

• Hashboard fault localizer — the interactive decision engine
• 0 ASIC troubleshooting overview
• S19j Pro: chain only find 0 ASIC
• S19 Pro: chain only find 0 ASIC
• S17: chain only find 0 ASIC
• T17: chain find 0 ASIC
• S19 hashboard not detected
• ASIC status showing “x”

Door 5 — Domain / voltage fault

Decisive test: sweep the voltage-domain test points on the suspect hashboard
after 2–5 minutes of stabilization. You should see every domain within
±50 mV of the others. A domain 100 mV or more below its neighbors indicates a
partial short in that domain; near zero means a shorted chip, LDO, or capacitor; high or absent
means an open LDO or cracked solder. The domain voltage equals the per-chip core voltage times the
chips per domain — series-wired domains are why one shorted chip drags its whole group down.
Board fork: voltage control is a PIC on S9/S17/S19-generation boards (a failed or
corrupted PIC reads as a dead 3.3 V rail — on the S19 measure U3 pin 2, on the S19 Pro
U6 pin 2, expect 3.3 V) but TAS5782M DACs on the Amlogic S21 (no PIC) —
identify your board before probing for a
chip that isn’t there.

Route:

• S19 hashboard voltage error
• Fault localizer — walks domain measurements to the component
• S9 PSU voltage drop

Door 6 — Temperature-sensor errors

Decisive test: scan the I2C bus. The temp sensors live at addresses
0x48–0x4F; a sensor that fails to answer, or a bus with SDA/SCL stuck low, produces phantom
overtemp shutdowns and impossible readings. Two traps: on S9-generation PIC boards the TMP75
sensors are not visible on I2C until the PIC enables hashboard voltage — a sensor that
“isn’t there” before voltage-on is normal, not a fault. And when several
subsystems fail together, suspect a stuck I2C bus rather than the sensors themselves. The S21
has no PIC at all (voltage runs through TAS5782M DACs), so PIC-era diagnostic habits mislead —
identify the board first.

Route:

• S19 temp-sensor failure
• “Read temp sensor failed” walkthrough
• Temperature too high (Temp1/Temp2 > 95°C)

Door 7 — PSU suspected

Decisive test: measure, don’t guess — and never trust the PSU’s own
LED, which can glow while the rail is out of spec. The S19j Pro’s APW121215a is rated for an
11.96–15.20 V output range (≈13.49 V shared-rail in live operation); the
older APW7 should hold 11.60–12.60 V under load. Two standing traps: APW12/APW17 are
200–240 V input only, and on dual-cord 17/19-series units both AC cords must be seated —
half-powered supplies produce exactly the “starts then dies” pattern.

Route:

• PSU multimeter test, step by step
• APW9/APW12 problems and solutions
• PSU voltage out of range
• APW12 red-LED fault codes
• Underpowered PSU symptoms
• S19 on 110V: insufficient power

Door 8 — Log signatures & firmware errors

Decisive test: capture the kernel log before rebooting — the evidence dies with
the restart (how
to copy it out). Then three commands read the machine’s own account of the fault:
cat /sys/class/hwmon/*/chip_count (detected chips per chain — fewer than spec →
door 4); echo '{"command":"devs"}' | nc localhost 4028 (the
CGMiner API’s per-chain hashrate, temperature and hardware-error counts, on any stock
Antminer); dmesg | grep -i "chain\|asic\|hash" for the enumeration lines.

Route:

• S19 kernel-log error decoder
• S9-series kernel-log diagnosis
• S17-series kernel-log diagnosis
• “Cannot Find Signature!!” on a web upgrade = signed stock firmware rejecting an
  unsigned package (2019+ boards): bricked-update
  recovery · S9 upgrade failed
• Firmware corrupted / bricked
• NAND boot-chain corruption — symptoms and recovery
• Kernel panic after overclocking

Board unknown? Start there instead

Doors 5, 6 and every recovery route above behave differently per control-board family. The
control board identifier resolves Zynq vs
BeagleBone vs Amlogic vs CVitek in under a minute — with a dead board, via software, or from the
silicon itself. For symptoms this tree doesn’t cover, the full
error-code library (650 entries) is searchable by model
and symptom.

Why does the decision tree keep asking which control board I have?

Because recovery paths and even the voltage-control hardware differ by board family, not by
model. A Zynq board recovers over SD; an Amlogic board only over micro-USB — and
post-September-2025 stock firmware blocks even that. Branching on the wrong board wastes hours;
the identifier takes under a minute.

What tools do I need before starting?

A digital multimeter, a screwdriver set, and network access to the miner cover doors 1–7.
Door 8 needs SSH or the web UI’s kernel-log page. Board-level fixes (reballing, MOSFET
rework) need a rework station — that’s the point where the
bench takes over.

Is it safe to keep a faulty miner running?

Depends on the door. A thermal or PSU fault: power it down — continued operation risks
cascading damage. A single dead chain with the others hashing: it will run, but the underlying
fault (often a failing voltage stage) tends to spread. Diagnose before it does.