Antminer Fans Spin But No Hashrate: Find the Break

Fans roaring, dashboard showing 0 TH/s. First, the good news: fans at full speed prove
your power path and fan control are alive — this is not a dead miner. The machine is telling you
the hashboards never came up, and the kernel log will tell you why. Fifteen minutes, no soldering
iron required to reach a diagnosis — with the expected value printed at every step.

Different symptom, different page: if the miner reports a fan error (“Fan lost”,
fan speed 0, tach faults), that’s the cooling system, not the chains — see the
fan speed error fix and
fan troubleshooting
overview. For all other symptoms, enter the
decision tree.

Step 1 — Read what the board detected

Action: log into the web UI and open Miner Status, or SSH in — and do it
before any reboot: rebooting destroys the evidence, and a zero-hashrate unit that
recovers
after reboot is its own diagnosis.
Command:

cat /sys/class/hwmon/*/chip_count

You should see the full chip count for your model on every chain. Three
patterns, three diagnoses:

• 0 chips on every chain — nothing enumerated at all: a chain-wide fault
  (power, clock, or communication). Go to Step 2.
• 0 chips on one chain — that board or its cabling: reseat its data ribbon
  first, then treat it as a single-board Step 2. Model walkthroughs:
  S19j
  Pro “chain only find 0 ASIC”,
  T17
  “chain find 0 ASIC”.
• Some chips, fewer than spec (say 52 of 63) — a chain break: the chain died
  between the last chip that answered and the one after it. That is a located fault — go to
  Step 4.

Two companion reads give the same story with more texture:
echo '{"command":"devs"}' | nc localhost 4028 (the CGMiner API — per-chain hashrate,
temps, hardware errors) and dmesg | grep -i "chain\|asic\|hash" for kernel-level
chain errors. Save the log first:
how to copy
the kernel log out. Decode specific log lines at
S19 kernel-log errors.

Step 2 — Chain-wide zero: check power to the board

Action: multimeter on the suspect hashboard’s voltage-domain test points,
after 2–5 minutes powered for stabilization.
You should see every domain alive and all domains within ±50 mV of
each other. The domain voltage equals the per-chip core voltage times the number of chips in the
domain — the chips in a domain are stacked in series, which is why domain readings are so
diagnostic.

• All domains dead: the board’s input stage — on the bench this is
  classically a failed boost circuit (expect 19–25 V at the boost output depending on
  model) or a shorted power MOSFET (near-zero resistance across the power input; continuity between
  any two of the MOS pins 1/4/8 confirms it). Component territory:
  hashboard short circuit.
• One domain near zero: a shorted chip, LDO, or capacitor inside that domain —
  a domain sitting 100 mV+ below its neighbors indicates a partial short.
  S19 hashboard voltage
  error covers the sequence.
• S19-series with domains healthy but a dead 3.3 V logic rail: suspect the
  PIC (measure its output — U3 pin 2 on the S19, U6 pin 2 on the S19 Pro, expect
  3.3 V). Note this is board-family-dependent: the S21 has no PIC at all — hashboard voltage
  there runs through audio-DAC chips, and PIC procedures don’t apply. Unsure which control
  board you have? Identify it first.

Step 3 — Power good, still zero chips: clock and communication

The clock: every chain needs its reference clock. With an oscilloscope on the
crystal’s CLK test point you should see a clean 25 MHz square wave. A
cracked or cold-soldered crystal (Y1) produces exactly this signature — power fine, zero chips,
no clock. Reflow or replace.

The UART: chip enumeration runs over a 115200 8N1 serial chain; on a
scope, healthy enumeration traffic opens with a 0x55 0xAA preamble. Enumeration that
succeeds sometimes and fails other times — different chip counts boot to boot — is the
UART-corruption signature (EMI or signal integrity), not a dead chip. No oscilloscope on the
bench? The observable proxy: random, changing chip counts across reboots point at signal
integrity; a stable wrong count points at a fixed break. Reseat and inspect the data ribbons
first — unstable miner
rectification covers the pattern.

These are the faults where a repair bench earns its keep. If the board is under warranty or the
tooling isn’t there, this is the handoff point:
component-level repair.

Step 4 — Partial chain: locate the break

What the count already told you: a chain reporting M of N chips broke between
chip M and chip M+1 — the enumeration walks the chain in order and stops at the break. The break
is either a dead chip (ESD, thermal stress, manufacturing) or a cold solder joint on the
signal-forwarding pins that pass clock and data to the next chip.

Two localization patterns worth knowing:

• Break lands exactly on a domain boundary: suspect the level-shifter between
  domains or a cold CLK-resistor joint rather than a chip — probe the clock and data signals on
  both sides of the boundary; present on one side and absent on the other convicts the boundary
  component.
• Break lands mid-domain: a chip fault. The bench technique is binary search
  (temporarily bridging the return signal at the chain’s midpoint to see which half answers),
  followed by reflow or replacement of the convicted chip.

Step-by-step localization with your actual measurements:
hashboard fault localizer.

Detected everything, still low or zero effective hashrate?

The chains are alive; the work path isn’t. Green LED with no hashing has
its own entry; zero-hashrate
states across pool and config causes are in
zero-hashrate
solutions; a low count of live chips per chain reads as
S19 low hashrate — missing ASIC
chips. A chain that enumerates fully but produces far fewer valid results than it should is
degraded chips returning a low nonce rate, an overclock past stability, or a pool-side rejection
problem — check hardware-error percentages in the CGMiner API output first (devs
above), review any overclock at
overclocking instability,
and if the numbers say the silicon is tired, down-tuning beats replacement. If every chain shows
zero but the control board boots cleanly, rule the PSU back in: a supply that sags under load
fails enumeration without ever looking dead —
underpowered PSU symptoms.

If it started after a firmware update

Fans-at-full with no hashing immediately after a flash is the signature of an incomplete or
rejected update rather than a hardware fault:
the bricked-update recovery guide is the
door, S9 upgrade failed the classic
case, and firmware
corrupted/bricked the error-code entry. Recovery media depend on your control-board family —
identify the board before flashing anything
else onto it.

The 10-second version

Where this page hands off

Different starting symptom? Enter through the
troubleshooting decision tree — this page
is its Door 3. Fault located but the fix means reflashing or a board swap? Recovery procedure
follows the control-board family, not the model:
identify the board, then use the
recovery playbook. Shorted chips are found fastest
with a thermal camera (the short is the hot spot at idle); opens are found by bisection — both
are bench work with fine-pitch rework at the end, where our
Montreal repair bench takes over.

Why do the fans run at full speed when the miner isn’t hashing?

Fan control comes up with the control board, before the hashboards enumerate. When the chains
fail to initialize, you get exactly this picture: board alive, fans commanded, zero hashrate.
That’s why the kernel log — not the fan behavior — is where the diagnosis starts.

Can I fix a “0 ASIC” chain by reflashing firmware?

Only if the cause was software. A chain that reads 0 because of a dead chip, failed crystal, or
shorted domain will read 0 on any firmware. Pull the kernel-log evidence first; if counts are
broken at the hardware level, reflashing just costs you an hour — and on Amlogic boards with
post-September-2025 stock firmware, a failed flash can leave you without a software recovery path
at all. Identify the board and check the lock tracker before flashing.

One chain is dead but two still hash — can I keep mining?

It will run at two-thirds hashrate, but the underlying fault — often a failing voltage stage —
tends to spread. Diagnose the dead chain now, while the repair is one board and not three.