Kernel Log

The kernel log is the most detailed diagnostic source on an ASIC miner, recording what the firmware sees as it boots each hashboard and runs the device. Accessible from the miner's web interface or over SSH, it reports per-chain ASIC chip counts, board temperatures, voltage and frequency settings, EEPROM read results, and the hardware errors the controller encounters in real time. For anyone diagnosing a fault, the kernel log is the first place to look, because it states exactly what the machine detected rather than what the spec sheet says it should have.

Reading chip counts

The single most useful line family reports how many ASICs each chain found during enumeration. At boot, the controller addresses every chip on a hashboard sequentially down the serial daisy chain and counts the responses. A message such as Chain[0]: find 0 asic means that chain detected no chips at all, while a healthy board reports the model's full expected count — 76 chips per board on an Antminer S19, 114 on an S19 Pro. The failure signatures split cleanly. A partial count (say, 40 of 76) points to a specific dead or pseudo-soldered chip breaking the chain at the first missing position, since every chip downstream of the break goes silent — the count itself tells you roughly where on the board to probe. A zero count usually points upstream of the silicon entirely: a data cable, a power issue, or an EEPROM read failure that made the firmware refuse to initialize the chain.

Using it for diagnosis

Because the log distinguishes cable faults from board faults, the classic first move is a swap test: exchange the data cables (or controller ports) between a good chain and the suspect chain, reboot, and re-read the log. If the zero-chip symptom follows the board, the board is faulty; if it follows the cable or port, the board is fine and you just saved yourself a teardown. The log also surfaces subtler evidence — temperature-sensor read errors, voltage-domain anomalies, PLL frequency ramping problems, and repeated chain restarts — that narrow down where on the board to look before you ever pick up a multimeter. Watch for patterns over time too: a chain that enumerates fully when cold but drops chips as temperatures climb is describing a thermal or solder-joint problem in plain text.

Where to find it and what comes next

On stock firmware, the log is exposed in the web UI's log page; over SSH, standard Linux sources like dmesg and the files under /var/log/ carry the same stream, and the mining daemon's API can report per-chain status alongside it. Capture the log before power-cycling when something breaks — a reboot wipes the evidence of what actually happened. The kernel log drives the rest of the repair workflow: it tells you which board to pull, the test fixture takes over to localize the fault to a chip, and the bench work begins from there. Reading it fluently is the cheapest diagnostic skill in mining — it costs nothing and routinely saves hours.

Beyond chip counts

Chip enumeration is the headline, but the supporting cast earns its keep. Temperature-sensor read failures appearing before a chain drops point at the sensor path or its wiring rather than the hashing silicon. EEPROM messages deserve close reading, since boards whose calibration data cannot be read are often refused outright by the firmware — a "dead" board with healthy chips. Fan RPM reports and the protections they trigger explain many mystery shutdowns, and PSU communication errors distinguish a power problem from a board problem before you unbolt anything. The discipline that ties it together is correlation: note the timestamp when hashrate fell, then read what the log says in the minutes around it, rather than skimming for anything red. And when a machine or board goes out for professional repair, ship the saved log with it — it tells the bench exactly where to start and routinely saves a diagnostic hour that would otherwise be billed.