Diagnostics · Antminer S21

What it means: The control board can't talk to any ASIC on that chain, so firmware powers the board off - you lose ~1/3 hashrate. Almost always a hardware/communication fault (cable/power), not config. Real log: 'check_asic_number: Chain 1 only find 0 asic, will power off hash board 1'.

Symptoms

• Status page shows a board at 0/xx chips
• Total hashrate down ~1/3
• Kernel log: 'find 0 asic' / 'data load fail'

Field procedure

1. Read the kernel log and note WHICH chain (0/1/2) is at 0.
2. Power the unit OFF at the PDU (never reseat cables live).
3. Reseat that board's signal ribbon AND its DC power cables - both ends. Reboot and recheck.
4. Still 0? Swap the ribbon with a known-good board (move one end): if the error MOVES, the cable is bad → replace it. If it STAYS, the board is bad.
5. Board still 0 after cabling is ruled out → tag it, pull it, RMA/swap the hashboard.

What it means: A board is hashing with fewer chips than nominal. A dead chip takes its whole DOMAIN, so losses come in contiguous domain-sized chunks. Scattered vs contiguous tells you chip-vs-domain.

Symptoms

• One board a domain short (a contiguous block missing) while the others read full
• Reduced total hashrate
• Higher HW-error/reject rate on one board

Field procedure

1. Confirm it persists across a reboot (transients happen).
2. Open the chip grid: are missing chips contiguous (a domain) or scattered?
3. Check board temps - an overheating domain drops chips; verify fans/airflow and PSU voltage in spec.
4. If chips stay missing and the count keeps dropping over days, flag the board for swap/RMA.

What it means: Firmware saw a fan at 0 RPM or outside its allowed range (normal ~3,000-6,000; min ~1,000-2,000) and stopped mining to protect the boards. A broken tach wire reports 'no fan' even while the blade spins.

Symptoms

• Unit stops/throttles shortly after boot
• Log: 'fan lost' / 'fan speed too low'
• One fan visibly not spinning

Field procedure

1. Identify which fan (front/rear) from the log/status page.
2. Power off. Reseat the fan's connector at the control board; check pins for damage/corrosion.
3. Spin the fan by hand - feel for a seized bearing or debris.
4. Swap in a known-good fan of the correct size/connector. Confirm the unit stays up and temps normalize.
5. If a good fan still reads 0 on that header (or there are burn marks), the control board header is bad → swap/RMA the unit.

What it means: A board exceeded its limit and throttled or shut down to save the chips (typical shutdown ~90 °C chip / ~80 °C PCB). Cause is airflow, ambient, dust, or a bad sensor - usually NOT the board. Real log: 'over max temp, pcb temp 85 chip temp 110'.

Symptoms

• Hashrate drops then unit stops
• Log: 'temperature is too high'
• High inlet/chip temps, or one sensor reading garbage (255)

Field procedure

1. Check the status page: is it REALLY hot, or is one sensor reading absurd (255/0)?
2. If genuinely hot: check ambient/inlet (aim <30 °C), confirm both fans spin, clear dust from heatsinks/exhaust.
3. Confirm the hot aisle isn't recirculating exhaust; keep ~30 cm clearance.
4. If a sensor lies (255) while neighbors read normal → sensor fault: reboot, reseat the board's data cable, reflash.
5. Once temps are back in range, restart and monitor.

What it means: A board isn't enumerated. One missing = that chain is dead or unpowered. ALL missing = suspect power delivery or the control board.

Symptoms

• Only 2 of 3 boards on the status page
• Log: 'Chain[2] not found'
• No boards at all

Field procedure

1. Note whether ONE board or ALL are missing.
2. One missing: power off, reseat that board's power + data cables, reboot; then swap the ribbon to isolate cable vs board.
3. All missing: verify the PSU delivers ~12 V to the hashboard connectors and reseat all power cables; test one board at a time.
4. All still missing with power OK → reflash firmware via SD card; still nothing → control board suspect.

What it means: The miner mines below its rating. Diagnose by PER-CHAIN behavior: one board low = that board; all boards down evenly = system-wide (thermal, PSU, or firmware). Unstable/spiky = network/pool.

Symptoms

• Average well below the model rating
• One chain much lower than the other two
• Spiky hashrate with pool disconnects

Field procedure

1. Baseline against the rating for THAT exact model + firmware version.
2. Check the per-chain split - each board should be ~1/3.
3. One board low → dead chips/partial domain on that board (reseat/clean; if it stays low, RMA).
4. All boards down evenly → check temps (throttle >85-90 °C), PSU sag under load, and frequency below default.
5. Unstable, not just low → fix the network/pool path (wired, static/reservation, stable link).

What it means: You can't reach the miner. It has no link, didn't get an IP, its IP changed, or the CB isn't responding.

Symptoms

• Not found in a scan
• No RJ45 link light
• Never appears in monitoring

Field procedure

1. Check Ethernet LEDs - normal is yellow steady + green flashing. Both off = cable/switch/CB.
2. Find the IP: router DHCP client list (Bitmain MACs often start C4:/D4:), a network scanner, or the IP-report button + IPReporter.exe.
3. Known IP but no page: ping it; if it replies but won't load, the web service hung → reboot.
4. Nothing at all: swap cable/switch port; try a direct laptop-to-miner link.
5. Still nothing → factory reset to the default 192.168.1.254, or SD-card recovery; no boot after that → swap the CB.

What it means: One pool Dead with backups Alive = that endpoint/URL is wrong. ALL pools dead = the miner's NETWORK path (internet/DNS), not three pools failing at once. Stale submissions involve outdated jobs; inspect the pool reject reason before attributing any rejection to computation or network faults.

Symptoms

• Pool shows 'Dead'
• Log: 'socket connect failed' / 'DNS resolve failed'
• Rising reject or stale %

Field procedure

1. One pool dead → fix that pool URL/port/worker; the miner fails over in priority order.
2. ALL pools dead → check internet, gateway, DNS (set 8.8.8.8/1.1.1.1) - it's the network, not the pools.
3. High STALE % → latency: go wired, use a closer endpoint, stabilize the link.
4. High REJECT % → capture the actual pool reject reason, job/session context and local hardware logs. Only pursue compute/tuning faults when corroborated; do not infer a degrading board from rejects alone.
5. Wrong worker name → fix the worker string (case-sensitive on many pools).

What it means: The CB can't read a hashboard's ID/EEPROM chip (holds chip-bin/calibration), so it skips the board. Usually a bad data connection or firmware/EEPROM mismatch. Related: 'chip bin not found'.

Symptoms

• Log: 'EEPROM read failed' / 'EEPROM exception'
• 'chip bin not found'
• One board skipped at startup

Field procedure

1. Note which chain throws it.
2. Power down, reseat that board's flat/data cable; try the board in a different slot if allowed.
3. Confirm you're on the CORRECT firmware for the exact hardware revision; reflash / SD-restore if unsure.
4. If the EEPROM still won't read after reseat + correct flash, the board is faulty → swap/RMA.

What it means: A power-delivery problem. A failing PSU can output UNSTABLE voltage that drops boards and lights the red LED even though the boards are fine - so rule out the PSU before condemning a board. Real log: 'error PSU lost' / 'V_IN abnormal'.

Symptoms

• Whole unit dead / no lights
• Red fault LED, random reboots under load
• Trips the breaker on power-up

Field procedure

1. Won't power on: confirm wall power and C19/C20 cord seating. Don't trust the PSU LED.
2. Measure DC output under load at the connectors: healthy ~11.6-12.6 V; below ~11.4 or above ~13.0 = PSU problem.
3. Trips breaker: full ASICs need a dedicated 200-240 V circuit (15-20 A). Move it; a repeated trip on a correct circuit = shorting PSU/unit.
4. Swap test: try a known-good compatible PSU, and/or test the suspect PSU on a known-good miner.