How to Read ASIC Miner Kernel Logs: A Symptom-to-Check Troubleshooting Guide

Published: 2026-09-01 Updated: 2026-09-01 Evidence checked: 2026-09-01

Read an ASIC miner kernel log by preserving the failure window first, then matching messages to the manufacturer, model, firmware, and subsystem before changing anything. Start with external checks for network, airflow, and power delivery; do not treat a single error line as a diagnosis. Export the complete log, record timestamps and symptoms, compare repeated events, and stop for qualified repair when the evidence points inside the PSU or energized hardware.

A miner log is evidence, not a universal error-code dictionary

An ASIC miner log records stages, state changes, warnings, and failures reported by its control software. It can narrow a fault to networking, cooling, power, a hashboard, a sensor, or the control system. It cannot prove that the first alarming line names the failed part.

Messages also change across brands, model families, control boards, and firmware. Bitmain's S19-series troubleshooting guide, for example, groups examples around fans, PIC communication, missing chips or hashboards, network faults, power faults, and overtemperature protection. The page explicitly limits those examples to the S19 family and says other models are for reference only. That limitation is the right starting point for every log: identify the exact machine before interpreting its vocabulary.

The useful question is not "What does this one line mean?" It is "What happened before and after this line, did the event repeat, and does the rest of the miner agree?"

Capture the failure before you reboot

A reboot may clear a current log, start a new time sequence, or make an intermittent fault disappear. Save the evidence before changing pool settings, firmware, work mode, network configuration, or hardware.

For supported Antminers, Bitmain's log-copy procedure distinguishes the current log used for a present fault from historical logs used for unstable or earlier behavior. It also instructs operators to copy the complete log, verify the pasted file, and select relevant dates when downloading history. WhatsMiner uses a different package: the official WhatsMinerTool export guide lists miner, system, power, API, and frequency-test logs in the export.

Preserve the original archive. Make a separate working copy for notes or redaction. A useful filename includes the miner asset name, model, capture time, and whether the problem was active, for example rack2-m60s-2026-09-01-active-fault.zip. Do not publish an unredacted log: it may expose IP addresses, MAC addresses, pool account names, or other operational identifiers.

Log-capture worksheet

Field	What to record	Why it matters
Miner identity	Brand, exact model, serial or asset label	Prevents a code from another model being applied by mistake
Software state	Firmware name/version and recent changes	Ties messages to the code that produced them
Time basis	Local time, time zone, miner clock, capture time	Lets you align the log with pool and power events
Visible symptom	Offline, zero/low hashrate, reboot loop, high temperature, missing board	Keeps the diagnosis tied to an observed failure
Log window	Start-up through the fault and recovery, not one isolated line	Preserves sequence and repeated events
External state	Link lights, inlet condition, breaker/PDU status, fan movement, pool worker state	Provides independent checks outside the log
Change history	Firmware, pool, network, power, cleaning, or tuning changes	Identifies a plausible trigger without assuming causation
Original file	Read-only archive plus file hash if your process uses one	Protects the evidence from accidental edits

Read the sequence in four passes

Reading every line from top to bottom is slow and encourages fixation on harmless startup noise. Use four passes instead.

Pass 1: establish the boot and time sequence

Find the beginning of the boot, the miner's clock, the first pool connection, and the first appearance of the symptom. If the clock is wrong, note the offset rather than silently correcting timestamps. Repeated initialization can indicate a reboot loop, but you still need the restart reason or an external power record before blaming firmware or the PSU.

Pass 2: find the first persistent fault, not the loudest line

Mark warnings that repeat after initialization or immediately before hashrate drops. A single sensor read failure followed by normal readings is different from the same failure appearing on every attempt. Keep the line before and after each event; context often shows whether the message is a cause, a recovery action, or a later consequence.

Pass 3: group messages by subsystem

Classify each repeated event into network/pool, airflow/temperature, power, hashboard/chips, control/firmware, or unknown. Do not replace the original wording with your diagnosis. The purpose of grouping is to choose the next check, not to declare a component dead.

Pass 4: compare the log with an independent observation

Use the pool's worker history for accepted work, the miner dashboard for averaged hashrate, a known-good network path, and visible power/cooling indicators. If the miner reports a pool connection but the pool sees no accepted work, follow the rejected-share troubleshooting process. If both real-time and averaged hashrate remain at zero, use the site's zero-hashrate guide alongside the model manual.

Symptom-to-check decision table

Log pattern and observed symptom	First low-risk check	Evidence that changes the branch	Stop or escalate when
Pool or network messages; worker offline	Confirm link lights, cable seating, address/gateway/DNS settings, pool endpoint, and another device's path	Pool history shows when accepted work stopped; another cable/port restores connectivity	The network path is known good but the miner still cannot establish or sustain a connection
Fan or temperature messages; reduced or zero hashrate	Check inlet obstruction, exhaust recirculation, visible fan movement, and manufacturer operating limits	Temperature falls after restoring airflow and the warning does not recur	A fan does not turn, a sensor remains abnormal, or protection repeats under compliant inlet conditions
Power or voltage messages; resets or missing boards	Check the external circuit/PDU state, approved cords/connectors, and whether the event aligns with a power interruption	A power-quality or PDU record matches the restart; the message disappears on a verified supported supply path	The log points inside the PSU, connectors show damage/heat, or the unit needs energized electrical testing
Missing hashboard/chip or board communication messages	Record which board/slot repeats and compare it across cold starts without opening the unit	The same board/slot fails consistently while power, network, and temperature are stable	Internal cables, boards, voltage measurement, swapping, or disassembly would be required
Repeated boot, watchdog, memory, or firmware messages	Record restart reason, firmware version, last change, and whether stock recovery instructions exist for that model	The issue began immediately after a documented change and the vendor provides a matching recovery path	Recovery is not model-specific, signatures/files are uncertain, or data must be preserved for support
Unknown code or mixed symptoms	Export the full vendor log set and collect photos/dashboard/pool timestamps	Manufacturer documentation maps the exact code for that model and firmware	No authoritative mapping exists or multiple subsystems fail together

This order deliberately keeps live electrical work and internal part swapping out of the first response. If a manufacturer procedure requires opening the miner, moving boards, or testing a PSU, power isolation, warranty terms, competence, and the model's service manual become separate gates.

Vendor fields do not translate one-to-one

Different vendors expose different evidence. A Bitmain log may show a plain-language fan or board message. WhatsMinerTool may require several exported files to connect a miner event with a power or system event. Canaan's A10/A11/A12 log guidance documents fields such as BOOTBY for restart reason, NETFAIL for connection timing, PS for power-supply state, and board-level temperature/status fields.

Those names are useful examples, not a translation table. Do not assume that an Antminer phrase, WhatsMiner error number, and Avalon field describe the same threshold or action. Record the exact string and consult the documentation for the exact family and firmware. If a support article says an example is only a reference for other models, preserve that limitation in your notes.

Build a short evidence chain before changing anything

A defensible diagnosis connects four observations:

1. Symptom: what the miner and pool actually did.
2. Sequence: the first persistent log event and what surrounded it.
3. Independent check: network, cooling, power, or pool evidence that agrees or disagrees.
4. Repeatability: whether the same event returns under the same conditions.

For example, a temperature warning plus blocked intake and recovery after airflow is restored is a stronger chain than a temperature line by itself. A missing-board message that repeats on the same slot with stable inlet conditions and no external power event is enough to escalate, but not enough to promise which internal component will fix it.

Avoid the common "change three things and see" approach. If you update firmware, move a cable, change a pool, and reboot at once, the next log cannot tell you which action mattered. Make one authorized, reversible change at a time, then capture the new result. The maintenance checklist can help separate routine external care from fault-specific repair.

Prepare a useful support packet

When the evidence points beyond low-risk checks, send support a compact packet instead of a screenshot of one line:

• exact brand, model, serial or asset label, and firmware version;
• original complete current/history export or vendor log archive;
• time zone and the approximate start/end of the fault;
• pool-side worker history or accepted-hashrate screenshot for the same window;
• photos of indicators and external connections, with credentials and personal data hidden;
• a list of recent changes and the one-at-a-time checks already performed;
• the exact recurring strings, with their surrounding lines left intact.

Keep the original log unchanged. Redact only the copy you share, and tell support what was redacted. If the unit is under warranty, follow the manufacturer's evidence and return process before opening it or replacing internal parts.

What the log still cannot tell you

Miner logs are getting richer, but they remain implementations rather than a shared diagnostic standard. Firmware can rename fields, suppress context, or report a downstream symptom after the initiating fault. Third-party firmware and fleet tools may add useful metrics while changing the vocabulary again.

The open question for operators is how much evidence to collect locally before relying on remote dashboards or automation. A small setup may need only preserved logs, pool alerts, and a disciplined worksheet. A larger site may benefit from synchronized power, network, temperature, and worker histories. In either case, the durable practice is the same: retain original evidence, document the model boundary, and require two agreeing observations before taking a disruptive action.

Frequently asked questions

Should I reboot an ASIC miner before saving the log?

Save the current log first whenever the interface is reachable and there is no immediate safety hazard. A reboot can replace the current boot sequence, clear useful context, or make an intermittent problem disappear. Record the visible symptom, miner clock, pool-worker state, and capture time, then export the complete current and relevant historical logs. Reboot only after the evidence is preserved and the manufacturer's procedure makes that step appropriate.

Is the first error line always the root cause?

No. Startup logs can contain transient warnings, and a later message may describe a consequence rather than the initiating fault. Find the first event that persists or repeats near the observed hashrate, temperature, connection, or restart change. Keep nearby lines and compare the result with an independent source such as pool history, link state, or airflow conditions. Treat the first line as a clue until the sequence and another observation agree.

Can I use an Antminer error message to diagnose a WhatsMiner or AvalonMiner?

Not reliably. Vendors and model families use different fields, error codes, thresholds, and recovery procedures. Even one manufacturer's support page may limit its examples to a particular series. Record the exact message, brand, model, control board, and firmware, then use the documentation for that combination. Cross-vendor material can suggest a subsystem to inspect, but it should not justify swapping parts, flashing firmware, or declaring a component failed.

What should I redact before sharing an ASIC miner log?

Work from a copy and keep the original archive unchanged. Review IP and MAC addresses, pool usernames or worker names, account identifiers, hostnames, remote-access details, and any tokens or credentials that a tool may include. Preserve timestamps, error strings, firmware versions, and the surrounding sequence because support needs that context. State what you removed so the recipient does not mistake a redacted gap for missing log data.

How much of the log should I send to support?

Send the complete relevant export when the vendor requests it, not only a screenshot of the alarming line. Also identify the fault window so the technician can find the sequence quickly. Include the exact model and firmware, time zone, symptom, recent changes, pool-side evidence, and checks already performed. If the archive is large, retain its original structure and let the support process determine which files matter rather than deleting unfamiliar entries.

When should I stop troubleshooting and arrange repair?

Stop when the next step requires opening energized equipment, probing a PSU, moving internal boards or cables without a model-specific service procedure, bypassing protection, or risking warranty evidence. Also escalate when the same internal-board or power fault repeats after verified external network, airflow, and supply checks. A log can justify escalation without proving which replacement part will solve the problem. Qualified repair should make that final determination.

References

• BITMAIN: How to copy new Kernel Log into text form
• BITMAIN: Common Problems and Solutions for ANTMINER 19 series
• WhatsMiner: Log and Data Export Q&A
• Canaan: Miner Log Technical Guidance for AvalonMiner A10, A11, and A12