Identifying and Rectifying Unstable Miners

An unstable miner is one that hashes, but not dependably: it reboots on its own, drops hashrate for minutes or hours, throws intermittent hardware errors, or falls off the pool and rejoins in a loop. Unlike a dead board, the hardware is fundamentally alive — something in the power, thermal, signal, or network chain is failing under load and recovering. This guide walks the fault tree in the order a bench tech actually works it: cheapest and most common causes first, teardown last. The goal is to isolate the single stage that is misbehaving instead of shotgunning parts.

First, define the instability

“Unstable” is three different failures wearing one coat. Pin yours before touching anything, because the diagnostic path forks here:

• Reboots / power-cycles — the whole unit restarts (fans spin down, kernel log resets). Points at power delivery, thermal protection, or the control board.
• Hashrate sag — the miner stays up but the reported hashrate drifts below nameplate, often with rising HW (hardware error) counts. Points at one weak hashboard, a heat problem, or an autotuner backing off frequency to stay stable.
• Pool disconnects — the miner is healthy but keeps dropping shares or reconnecting. Points at the network path, not the machine.

Read the kernel log before you assume. In the web UI it is under Miner Status / Kernel Log (or System → Log on custom firmware). Note whether errors name a specific chain (Chain0/1/2), a temperature event, or a network timeout — that one line usually collapses the search space by two thirds.

Tools you will want

• True-RMS multimeter (for wall-voltage and DC-rail checks)
• Clamp meter or a plug-in power meter that reads voltage under load
• A known-good PSU of the same generation, for swap testing
• A known-good Ethernet cable and a spare switch port
• Thermal paste and a thermal camera or IR thermometer (only if you get to the heat stage)
• The correct service manual for your model — grab it from the manuals library

Work the fault tree in order

1. Power delivery — the single most common cause

Voltage sag under load causes more “random” reboots than every other cause combined. When the boards demand peak current, an undersized circuit or a marginal PSU can droop below the miner’s brown-out threshold, and the unit resets.

1. Check the wall circuit first. A modern S19/S21-class miner pulls 3–3.5 kW. On a single 15A/120V circuit that is roughly the whole breaker — there is no headroom, and inrush or a co-tenant load will sag the line. These machines belong on a dedicated 200–240V circuit. Note the nuance on Bitmain PSUs: an APW9/APW9+/APW8/APW3 will run on 110/120V, but it delivers reduced output there — it only makes full rated wattage on 200–240V. A big miner starved to partial PSU output will throttle, drop chains, or reboot. Do not read “it powers on at 120V” as “it is properly fed.”
2. Measure voltage under load, not idle. A plug-in meter showing 240V at rest tells you nothing. Watch it while the miner ramps to full hash. A dip of more than a few volts under load means the circuit, the cord, or a loose lug — not the miner.
3. Swap the PSU. A failing supply whose output ripples or collapses at peak is famously hard to catch with a meter because it only misbehaves for milliseconds. The fastest test is substitution: drop in a known-good same-generation PSU and see if the instability follows the supply or stays with the miner. Never open a PSU shell. The mains-side PFC bulk capacitors inside hold a lethal charge long after unplugging; the sealed unit is not a field-serviceable part — replace it whole.
4. Reseat the DC feed to the boards. On S17/S19/S21-generation machines the hashboards are fed by bolted copper bus-bars; a loose or lightly oxidized bolt becomes a resistive hot joint that drops voltage and reboots the board under current. Power down, unplug, and torque each lug clean and tight. (The older S9 feeds each board through its own power connector rather than a shared bus-bar — reseat those connectors instead.) The DC side is low voltage (roughly 12–21V) and is not a shock hazard — but it can push enormous current. A dropped tool or a slipped wrench across a bus-bar will arc and vaporize metal. De-energize before you touch it.

2. Heat — the hidden throttle behind hashrate sag

If the miner runs fine cold and degrades after it warms up, suspect thermals. Firmware protects the silicon: on an over-temperature event (commonly around >75°C at the chip) it will hold reset and cut domain voltage, which reads to you as a chip dropping out, a chain going offline, or the whole unit cycling.

1. Confirm intake air is cool and unobstructed and that both fans actually ramp. A single lazy fan will cook one end of the boards.
2. Clear dust from the heatsinks — a felted intake face is a slow strangle that only shows up at full load.
3. If one specific chain reports high temps or intermittent drop-outs, the likely culprit is dried or pumped-out thermal paste / a lifted heatsink on that board. Re-pasting is a board-level repair, not a config change.
4. Watch per-board temperature spread in the UI. A board running markedly hotter than its siblings at the same frequency is the one to pull.

3. A single weak hashboard

When total hashrate lands well under nameplate and one chain shows a low chip-enumeration count (fewer chips detected than the board should have) or climbing HW errors, you have a board-level fault, not a system-wide one.

1. Read the enumerated chip count per chain in the kernel log. A chain that finds, say, far fewer chips than its siblings has a broken ASIC chain — the count usually pinpoints roughly where along the string it breaks.
2. Remember voltage is regulated per domain, not per chip: a cluster of chips shares one DC-DC converter. A shorted chip collapses its whole domain’s voltage, which is why one bad chip can knock out a group and drag the board.
3. To confirm which board is guilty, run the miner on two known-good boards plus the suspect, or swap chains between slots and see if the fault follows the board. If it does, that board needs component-level diagnosis — walk it with the ASIC fault finder.
4. Chip-level and domain-level repair means reflow, chip replacement, or converter work. Source the repair parts against your model before you commit.

4. Control board / firmware

The control board is the miner’s brain — it runs the mining software, talks to the pool, and clocks the hashboards over the ribbon interface. When it is the problem, the failure is usually erratic: random reboots, a UI that hangs, or a unit that mines for a while then wedges.

1. Start non-destructively: power-cycle from a cold state, then try a clean reflash of the same firmware version. A corrupted filesystem or a half-applied update causes exactly this kind of intermittent behavior.
2. A factory reset clears a bad config, but it also wipes your pool/tuning settings — record them first.
3. Check the ribbon cables between control board and hashboards. A marginally seated or nicked 18-pin ribbon produces flaky signal that mimics a bad board — reseat all three before condemning anything.
4. If clean firmware on good hardware still wedges, the control board itself is suspect. It is a replaceable module; match the correct board to your exact model rather than assuming cross-compatibility across a family.

5. Network — when the miner is fine and the link is not

Pool-disconnect loops with an otherwise-healthy miner are a wiring or path problem, not a hardware fault. Rule it out cheaply before you open anything:

• Swap the Ethernet cable for a known-good one and move to a different switch port.
• Confirm the miner holds a stable IP (a DHCP lease that keeps changing looks like “random” drops).
• Check the pool endpoint and a backup pool — a flapping upstream route drops shares in a way that looks like miner instability.
• Keep the machine on wired Ethernet. Powerline adapters and marginal PoE runs are a frequent source of phantom disconnects in a hashcenter.

6. Electromagnetic interference and grounding

Miners are dense switching supplies packed with high-current DC. In a cramped or poorly grounded install, EMI and ground bounce can genuinely upset the control logic and cause resets — but this is a diagnosis of exclusion, reached only after power, heat, boards, and network are cleared. Ensure the chassis and rack are properly grounded, keep signal cabling away from the PSU and DC bus, and don’t bundle Ethernet along a power run.

How to confirm the fix worked

One clean reboot proves nothing — instability is by definition intermittent. Verify under sustained load:

1. Let the miner run at full hash for several hours and confirm the kernel log stays clean of reboot, over-temp, and chain-drop events.
2. Confirm reported hashrate holds at or near nameplate and that HW-error accumulation is flat, not climbing.
3. Confirm all expected chips enumerate on every chain and per-board temps sit in a tight range.
4. Confirm the pool shows a steady accepted-share stream with no reconnect churn.

If any one of those regresses over a multi-hour window, the fault is still live — go back to the stage that failed.

When to escalate

Wall power, PSU swaps, cable and connector reseats, dust, and firmware reflashes are all owner-serviceable. Once the fault is isolated to a single hashboard — dead chips, a collapsed voltage domain, a power-MOSFET short — you are into microsoldering, and that is bench work. If you have narrowed it to a board but don’t run a hot-air station and a bench supply, start a repair and let the diagnosis and part-level work happen on the bench rather than risking a good board.

Related: Pinpoint a board-level fault with the ASIC fault finder, pull the correct service documentation from the manuals library, and source components from ASIC repair parts.