The kernel log is the single most useful diagnostic on an Antminer S9-series miner: the firmware writes every boot stage, chain probe, and fault to it in plain text. Read correctly, it tells you which of the three hashboards failed, where in the signal chain, and whether the fault is thermal, power, communication, or fan-related — before you open a case. This guide maps the S9’s common kernel-log messages to their real cause, the confirming test, the fix, and how to verify.
How to pull and read the S9 kernel log
Open the miner’s web interface at System → Kernel Log. At boot the firmware probes all three hashboards — labelled Chain0, Chain1, Chain2 — and reports what it finds on each. Read from the top: the sequence runs in order, so the first error is usually the root cause and everything after it a downstream symptom.
Know the healthy baseline first. A good S9 hashboard carries 63 BM1387 chips (189 across the three boards), grouped into 21 voltage domains of 3 chips each at roughly 0.40 V per domain — about 8.4 V DC end to end. Any board reporting fewer than 63 ASICs has a break in that chain.
Chain finds too few ASICs (missing chips)
What you see: a chain finds fewer than 63 ASICs. The count tells you where the chain breaks: the chips are daisy-chained over a UART line, so the firmware sees every chip up to the fault and nothing past it.
Cause: the signal chain is broken at a specific chip or voltage domain — a cracked BM1387, a cold solder joint, a dead domain LDO, or heat-cycled pads. This is a board-level fault, not a PSU fault. Replacing the power supply here fixes nothing.
- Note the count — it pinpoints where the chain died (a board stopping at 42 broke at the 43rd chip).
- Reseat the 18-pin signal ribbon at both ends — a partially seated cable mimics a mid-chain chip failure.
- If that doesn’t restore the count, the board needs bench work: use thermal imaging or a domain-voltage sweep to isolate the bad chip, then reball or replace it.
Verify: reboot and confirm the chain reports the full 63 ASICs and its CRC counter stays near zero.
Chain powered off / missing hashboard
What you see: the firmware powers off a whole hashboard, or a chain reports zero ASICs — a total loss of communication or power to that board (dead signal cable, no boost voltage to the domains, or a failed power feed).
- Confirm the signal ribbon and the board’s own power connector are seated, clean, and locked.
- Swap the board’s signal cable with a known-good one before condemning the board.
- If the board is dead on every control board and cable, the fault is on the hashboard itself — the boost circuit or a shorted domain.
Safety: the hashboard rails are low-voltage DC and are not a shock hazard. The danger is inside the PSU: the S9’s APW3++/APW7 supplies hold mains-side bulk capacitors around 410–420 V for minutes after unplugging. Never open a PSU — diagnose it as a sealed unit.
High CRC error counter
What you see: a rising CRC error count on one or more chains, usually with unstable hashrate rather than a hard stop — corruption on the UART return path, data from the chips failing its checksum. Almost always a signal-integrity problem: a marginal or dirty signal cable, a chip on the edge of stability, or a drifted domain voltage.
- Reseat and, if you can, swap the signal ribbon for that chain — the cheapest and most common fix.
- Check intake temperature — CRC errors climb as boards run hot; a chip that passes cold fails once the domain warms up.
- If the count persists on a good cable at normal temperature, the chain has a failing chip or domain and needs board-level diagnosis.
PIC error
Cause: the control board can’t talk to a hashboard’s PIC16F1704 microcontroller — the chip that manages that board’s voltage ramp over I2C at power-up. The usual culprit is the signal cable carrying the I2C lines.
- Reseat the signal cable at both ends; the I2C lines share that ribbon, so a poor connection reads as a PIC failure.
- Reflash with the correct official signed firmware image for your exact S9 model from the manufacturer — never a random build or another model’s firmware.
- If the error follows one hashboard to a known-good control board, that board’s PIC has failed; if it stays put, the control board is the fault.
Fan error
What you see: a fan fault, or a speed of zero or below the required RPM. The firmware reads RPM over the 4-wire connector and refuses to mine if a fan is missing or stalled.
- Confirm both fan connectors are seated and the blades spin freely — dust-packed bearings drag RPM below the firmware’s floor.
- Swap in a known-good 4-wire fan of the same rated speed; if the error clears, the fan is dead.
- If a known-good fan still errors on that header, the control board’s fan drive/sense circuit has failed.
Overtemperature protection
What you see: an over-temperature condition that stops a board or the whole miner. This is a protective shutdown — a hashboard sensor crossed the safe limit. The S9 is air-cooled, so the fix is airflow and thermal contact.
- Clear intake and exhaust: pull the fan grills, blow out packed dust, and confirm nothing blocks the airflow path through the boards.
- Check the rack — recirculating hot exhaust into the intake trips overtemp even on a clean miner.
- If one board consistently runs far hotter than its neighbours at the same load, its heatsinks or thermal pads have degraded and it needs re-pasting.
Pool / network connection errors
What you see: the miner cannot reach its pool. On a network or pool loss the S9 firmware idles — it does not run the boards at full power.
- Re-check the pool URL, port, and worker exactly as entered — one wrong character is the most common cause.
- Confirm the miner has a valid IP, then ping the pool host from the same network to prove DNS and routing.
- Reseat the Ethernet cable and try a different switch port — a flaky cable looks identical to a pool outage in the log.
Common mistakes and when to escalate
- Swapping the PSU for a missing-chip fault. Missing ASICs are a signal-chain break on the board; the PSU is fine.
- Assuming the whole board is dead. Reseat the signal cable first; a loose ribbon fakes nearly every symptom here.
If reseating cables and swapping fans doesn’t clear the fault, the failure is on the hashboard or control board and needs bench work — domain-voltage measurement, thermal imaging, chip-level rework.
Related: narrow a suspect board with the ASIC fault finder, read up on the voltage domain and PIC microcontroller that show up in these logs, or start a repair when a board needs chip-level work.
