Troubleshooting Common Problems of Antminer (19 Series)

The fastest way to diagnose a sick Antminer S19-series unit (S19, S19j, S19 Pro, S19j Pro, S19 XP, S19K Pro and the Hydro variants) is to read its kernel log before you touch a screwdriver. The log names the exact subsystem that failed — fan, hashboard voltage controller, ASIC count, network, power delivery, or thermal protection — and every error string below maps to a specific hardware cause. This guide walks each one from cause to diagnosis to fix to verify, using the real board architecture of the 19-series so you fix the right part the first time.

Reading the Kernel Log First

The log is the miner’s flight recorder. To open it:

1. Type the miner’s IP address into any browser (Chrome, Firefox, Brave).
2. Sign in with the web credentials (Bitmain stock default is root/root; change this immediately on a production unit).
3. Open Miner Status → Kernel Log.

The current log covers everything since the last boot — read this when a miner is actively faulting. The historical log keeps a rolling window of prior boots and is where you look for intermittent faults on a unit that looks healthy right now. Copy the failing line verbatim; the strings below are what Bitmain firmware actually prints.

ERROR_FAN_LOST — Fan Fault

Cause: The firmware polls each fan’s tachometer. A missing, stalled, or slow fan (below its RPM floor) trips ERROR_FAN_LOST and the miner refuses to hash to protect the chips.

1. Power down and reseat the 4-pin fan connectors at the control board — a lifted or corroded pin is the most common cause.
2. Check the fan cable for chafing or a severed tach wire, and spin each fan by hand. One that won’t free-spin, grinds, or wobbles has a failed bearing.
3. Swap in a known-good 6000–6800 RPM 12V fan of the correct 12×12×38 mm size and confirm it reports RPM.
4. If a good fan on a good port still reads zero, the fan header or its driver on the control board is dead — the board needs bench repair.

Verify: All fans report a non-zero RPM in the web UI and the fault clears on the next boot.

“fail to read pic temp” — Hashboard Controller Not Answering

Cause: Each hashboard carries a small microcontroller that manages the DC-DC voltage domains and relays board temperature to the control board over I2C. On the S17/S19-class boards that part is the dsPIC33EP16GS202, but the symptom is the same regardless — the control board sent an I2C request and got no valid reply, so it can’t read temperature or set voltage on that board.

1. Power down and reseat both ribbon/signal cables between the control board and the affected hashboard. A single bent pin or a cable seated one position off will kill I2C on that channel.
2. Move the suspect hashboard’s data cable to a known-good control-board port. If the fault follows the board, the controller or its I2C bus on the hashboard is the problem; if it stays on the port, the control board is at fault.
3. Reflash the miner with the correct official, signed Bitmain firmware image for that exact model from the manufacturer portal. A corrupted firmware can lose the ability to talk to the controller; never load an image built for a different model or an unsigned build.
4. If a good cable on a good port still fails, the hashboard’s voltage/temp controller is dead — that is a component-level bench repair, not a field fix.

Verify: All three boards report live temperatures and the “fail to read pic temp” line does not return after reboot.

Missing Chips or Undetected Hashboard

Cause: The firmware counts ASICs during boot. On these boards the chips are wired in series domains — the S19 runs 76 chips across 38 domains (2 chips each), the S19 Pro runs 114 chips across 38 domains (3 chips each). Voltage is set per domain, not per chip, so one open chip drops its whole domain and the count falls in a fixed block, not by one.

1. Low ASIC count on one board: reseat the hashboard data cable and reboot. If the same count returns at the same position every boot, a chip or its domain has failed — that board needs bench-level diagnosis (heat-gun/continuity work on the dead domain), not a parts swap.
2. A whole hashboard reads 0 or “not detected”: power down and check that board’s power connection to the bolted copper bus-bar — a loose or under-torqued bolt starves it. Reseat the data ribbon as well.
3. Do not chase a dropped domain by swapping the PSU; a bad power supply takes down all three boards evenly, not one chip block on one board.

Verify: All three boards report their full rated ASIC count (228 total on an S19/S19j, 342 on an S19 Pro) and a stable hashrate.

Network Failure

Cause: The miner can’t reach its pool or the LAN. When the network or pool drops, 19-series firmware idles and keeps retrying — it does not run at full power into a dead connection.

1. Reseat the Ethernet cable at both ends and confirm link/activity LEDs at the miner’s RJ45. Swap the patch cable — a marginal cable is the usual culprit.
2. Confirm the miner pulled an IP (check your router’s DHCP table, or run Bitmain’s IP Reporter, which makes the miner announce its own address to a broadcast request).
3. Verify the pool URL, port, and worker name, and check that ping/latency to the pool is sane. High packet loss shows up as frequent reconnects in the log.

Verify: The miner holds a stable pool connection and accepted shares climb steadily.

Power Failure

Cause: A power fault means a hashboard isn’t getting clean DC. On the 19-series, power moves from the PSU to the boards over a bolted copper bus-bar, and the PSU takes an enable/sense signal from the control board.

1. Confirm your input voltage first. The S19-series ships with an APW12-class PSU that requires 200–240V AC — it will not deliver rated output on 120V. Under-volting the input is a leading cause of phantom “power failure” and dropped-board faults on these units.
2. Power down and check the copper bus-bar bolts for tightness and for oxidation/burn marks at the contact faces. A loose bar arcs and browns the terminals.
3. Inspect the PSU control/sense wire to the control board for looseness or damage.
4. Load-test or substitute a known-good PSU of the correct wattage. If a good PSU on good bus-bar bolts still faults, suspect the control board’s power sequencing.

Safety: The DC bus-bar side runs at low voltage (roughly 12–21V) and is not a shock hazard, but the AC/PFC section inside the PSU holds capacitors charged to ~400V long after unplugging. Never open a PSU without letting it discharge; treat it as a sealed unit and replace rather than repair.

Overtemperature Protection

Cause: On-board temperature sensors (TMP75/TMP451-class I2C parts) feed the firmware; when a board crosses its ceiling the miner throttles or shuts down to save the chips.

1. Power down and inspect each hashboard’s heatsinks for dust, lint, or insect nests — blocked fins wreck heat dissipation. Blow them out and let the unit cool before restart.
2. Check intake air temperature and make sure exhaust flows freely with no recirculation of hot air back into the intake.
3. Keep ambient in the recommended 5–35°C band. If a single board runs hot while the others are fine, its thermal paste/pad or heatsink bond may have degraded — a bench reseat job.

Verify: All boards settle into a normal temperature spread under load and the overtemp line stays out of the log.

Note for Hydro / immersion S19 variants: these are fanless and liquid-cooled — the air-cooling steps above don’t apply. Check coolant flow, pump pressure, and for leaks or air locks instead.

Related Guides

Work symptoms into root cause with the ASIC Fault Finder, source the fans, cables, PSUs, and controllers you need from ASIC repair parts, and when a fault lands at the bench — a dead domain, a failed controller, or a browned bus-bar — start a repair with us.