KA3 log diagnosis and processing

The Antminer KA3 is a Kaspa (kHeavyHash) miner built on three hashboards, and its kernel log is the fastest, cheapest diagnostic you have. Nearly every fault the KA3 throws — a dead board, a failed fan, thermal shutdown, a stalled pool — announces itself as a specific string in the log before the hashrate graph flatlines. This guide maps the KA3’s most common log signatures to their real-world cause, the checks that confirm each one, and the fix. Read the log first; swap parts second.

How to read the KA3 log

The strings below all come from the same kernel log the firmware writes as the miner boots and runs. On stock Antminer firmware, browse to the miner’s IP on your LAN and open the status/log view — the live kernel log and the per-chain chip counts render on the same page. If SSH is enabled you can also tail the running log, useful for catching a fault that only appears once the unit warms up. When you open a repair ticket, export the full log and attach it: it tells the bench exactly which chain failed and where enumeration stopped.

The KA3 numbers its hashboards chain=0, chain=1, and chain=2. Any message that names a chain is pointing you at a physical board you can pull and inspect.

Safety before you open the case

The KA3 is a 200–240 V input-only machine — its PSU will not start on a 120 V circuit, so confirm you are on the right feed before chasing a “dead board.” Inside, the low-voltage DC bus-bar that feeds the hashboards runs at roughly 15 V and is not a shock hazard. The danger lives on the mains side of the power supply, where the PFC bulk capacitors hold on the order of 400+ V for minutes after you unplug it. Never probe or unscrew inside the PSU shell. Unplug, wait, and keep your work on the hashboard/control-board side.

“computing board can not find the chip” — power fault

A log line reporting that a computing board cannot find the chip means the control board tried to enumerate the ASICs on a chain and got nothing back. On the KA3 this is most often a power delivery problem, not a dead chip: if a board receives no voltage from the PSU, its entire chip string is invisible.

1. Power down and unplug. Confirm both bolted copper bus-bar lugs from the PSU are torqued down — a loose or arced bus-bar screw is the classic cause. Re-seat and tighten to a snug, flat contact.
2. Re-seat the signal/data ribbon between the control board and the affected chain.
3. Power back up and re-read the log. If the same chain still finds zero chips, move the PSU output to a known-good board (or swap in a known-good PSU) to isolate whether the fault follows the board or the supply.

If a board that receives clean voltage still enumerates no chips, the fault is on the board itself — a broken chip-string domain, not the power supply.

“sweep error string = F:1” — fan fault

A sweep error naming a fan position (for example F:1) means the firmware’s fan tachometer read a speed outside its safe window — a stalled, unplugged, or dying fan. The KA3 will refuse to ramp or will protect-shut if it can’t trust its airflow.

1. Inspect all fans for debris, seized bearings, or a disconnected tach lead. A fan that spins by hand but reads zero RPM is usually a bad bearing or a broken tach wire.
2. Swap the suspect fan for a known-good unit of the same voltage, size, and connector pinout. Re-test and confirm the sweep error clears.
3. Do not run the KA3 with a fan bypassed or a resistor spoofing the tach signal. The firmware trips on airflow for a reason — defeating it is how boards cook.

Fewer than three chains detected — dropped board

The KA3 expects to see all three chains. If the log shows only two (or one), a board has dropped out. This overlaps with the power fault above but is worth confirming as a count first:

1. Note which chain is missing from the log, then power down and pull that board’s data ribbon and bus-bar connection.
2. Re-seat both ends of the ribbon — a partially seated connector is the single most common cause of a phantom missing board — and re-check the bus-bar screw torque.
3. Power up and confirm all three chains report. If the board stays missing after clean re-seating and confirmed voltage, it needs bench-level diagnosis (domain-level voltage tracing across the chip string).

“high temp” / poweroff=true — thermal protection

A log entry with poweroff=true and a high-temp message means thermal protection tripped and shut the miner down to save the chips. A reboot clears the state, but if you reboot without fixing the cause it will trip again — and repeated thermal cycling degrades hardware. Treat it as an environment problem until proven otherwise:

• Ambient: the KA3 dumps a lot of heat. Confirm the intake air is genuinely cool and that hot exhaust is not being recirculated back into the intake.
• Airflow path: check for dust-clogged heatsinks, blocked intake mesh, or foreign objects in the fan path. A choked intake raises chip temps even when the room is cool.
• Fans: a fan running below spec (see the sweep-error section) reduces airflow without fully failing — a common cause of intermittent thermal trips.
• Sensors: if one chain reports implausibly high temps while airflow is clearly fine, suspect a bad temperature sensor on that board rather than a real over-temp.

Clean the heatsinks, restore airflow, then reboot and watch the log to confirm the trip does not return under load.

“No servers could be used” — pool fault

This one is not a hardware fault. No servers could be used means the KA3 booted fine but cannot reach any configured pool, so it has nowhere to submit work.

1. Verify the pool URL, port, and worker credentials in the config — a typo, a stale stratum host, or the wrong port is the usual culprit.
2. Confirm the miner has a valid IP and can reach the internet. A DHCP hiccup or a firewall blocking the stratum port looks identical to a “bad pool” in the log.
3. Add a working backup pool. If the miner locks onto the backup, the primary host or your route to it is the problem, not the KA3.

Note that a KA3 which loses its pool does not keep drawing full power — the firmware idles the boards until it can submit work again, so a pool fault costs you shares, not hardware.

When to escalate

Send a board for bench repair when: a chain enumerates zero chips despite confirmed clean voltage and a re-seated ribbon; a board stays missing after clean re-seating; or one chain reports impossible temperatures with airflow verified good. These are domain-level and sensor-level faults that need probing, not swapping. Only ever flash official Antminer firmware pulled from Bitmain’s own support portal — never a third-party image from an unknown source — and export the full log first so the bench can see exactly where enumeration stopped.

Related: Cross-reference the failing chain against the ASIC fault finder, source fans, ribbons, and bus-bar hardware from ASIC repair parts, and when a board needs bench-level work, start a repair with your exported KA3 log attached.