How to Read ASIC Miner Kernel Logs: The Complete Diagnostic Guide

Introduction — Your Miner Is Talking. Are You Listening?

Every ASIC miner you own is constantly writing a diary. Every second it runs, it records chip initializations, temperature readings, voltage adjustments, pool connections, share submissions, fan speeds, errors, warnings, and failures. This diary is the kernel log — and it is the single most powerful diagnostic tool available to any Bitcoin miner operator.

Most home miners never look at their kernel logs. They monitor hashrate from a pool dashboard, glance at the web interface occasionally, and only dig deeper when something breaks. By then, the log is a wall of text that looks like the Matrix. This guide changes that. We are going to teach you to read kernel logs the way D-Central’s repair technicians do — systematically, pattern by pattern — so you can diagnose problems yourself, catch failures early, and speak the same language as professional repair teams when you need help.

ThanosMining published a basic kernel log overview. This is not that. This is the definitive reference — built from eight years of real repair data across thousands of miners that have passed through our Laval workshop. We have seen every failure mode, every cryptic error string, every misleading log message. This guide distills that experience into something you can use at your workbench today.

What Are Kernel Logs?

An ASIC miner is a specialized computer. It runs a stripped-down Linux operating system — typically a custom build based on OpenWrt or a similar embedded Linux distribution. Like any Linux system, it maintains logs that record every significant event from the moment it powers on.

The term “kernel log” in the mining context actually encompasses two layers of logging:

1. The Linux kernel log — system-level messages about hardware initialization, driver loading, memory allocation, network interfaces, and device detection. Accessed via the dmesg command.
2. The mining software log — messages from the mining application itself (cgminer, bmminer, bosminer, or the specific firmware’s mining daemon). This is where you find chip detection, hashrate reports, pool communication, ASIC errors, and temperature readings. Stored in various log files depending on the firmware.

When miners and repair technicians say “kernel log,” they usually mean both layers combined — the full system output visible in the miner’s web interface log viewer. Both layers matter. The kernel log tells you whether the hardware initialized correctly. The mining software log tells you whether the hardware is performing correctly.

Why Kernel Logs Matter

Kernel logs answer questions that no dashboard can:

• Was every ASIC chip detected during boot? — A dashboard might show “3 hashboards detected” but the log reveals that chain 2 found only 60 of 63 chips. Three dead chips are eating your hashrate silently.
• What happened right before a crash? — The log preserves the sequence of events leading to a failure. Temperature spiked? Voltage dropped? A specific chip started throwing nonce errors 30 minutes before the board went offline? The log knows.
• Is the problem hardware or software? — A hashboard that fails to detect at the driver level (kernel) is a different problem than a hashboard that detects but fails to hash (mining software). The log distinguishes these immediately.
• Is the problem getting worse? — Comparing logs over time reveals degradation patterns. A chip that throws one error per hour today might throw ten per hour next week. The log lets you track the trajectory.

How to Access Kernel Logs

Every ASIC miner platform provides at least one way to view the kernel log. Most provide two: a web interface viewer and SSH access. The web interface is easier. SSH access gives you more power to filter, search, and save logs. Learn both.

Antminer (Bitmain Stock Firmware)

Web Interface Method:

1. Navigate to your miner’s IP address in a web browser (e.g., http://192.168.1.100)
2. Log in with your credentials (default: root / root)
3. Go to System → Kernel Log
4. The full log is displayed in a scrollable text box. Use your browser’s Ctrl+A to select all, then Ctrl+C to copy.

SSH Method (more powerful):

# SSH into the Antminer (default: root / root)
ssh [email protected]

# View the Linux kernel ring buffer
dmesg

# View the mining software log (path varies by model/firmware)
# S9 series:
cat /var/log/messages

# S17/T17 series:
cat /var/log/messages

# S19/S21 series (newer firmware):
cat /tmp/log/bmminer.log

# View the full system log with filtering:
cat /var/log/messages | grep -i "chain|error|temp|fan|freq"

# Follow the log in real time (watch new entries appear):
tail -f /var/log/messages

# Save the full log to a file you can transfer:
cat /var/log/messages > /tmp/miner_log_$(date +%Y%m%d).txt

Whatsminer (MicroBT)

Web Interface: Whatsminer’s web interface provides a “Log” tab, but it often truncates the output. SSH is the reliable method for Whatsminers.

SSH Method:

# SSH into the Whatsminer (default: root / root — older firmware)
# Newer firmware may require the admin password set in the web UI
ssh [email protected]

# View the kernel log
dmesg

# View the mining software log
cat /tmp/log/btminer.log

# View log directory contents (Whatsminers store multiple log files)
ls -la /tmp/log/

# Follow live log output
tail -f /tmp/log/btminer.log

Braiins OS / Braiins OS+

Web Interface:

1. Navigate to the miner’s IP address
2. Go to System → Log (or System Logs)
3. Braiins provides structured log output with severity levels and timestamps

SSH Method:

# SSH into Braiins OS (default: root / root, or your configured password)
ssh [email protected]

# View system log
logread

# View bosminer log specifically
cat /tmp/log/bosminer.log

# Follow live output
logread -f

# Filter for errors only
logread | grep -i "error|fail|warn"

Braiins OS produces some of the cleanest log output in the industry — structured, timestamped, with clear severity levels. If you are running Braiins, log analysis is significantly easier than stock firmware.

AxeOS (Bitaxe)

Web Interface:

1. Navigate to your Bitaxe’s IP address (or use http://bitaxe.local if mDNS is working)
2. Click the Logs tab in the web interface
3. AxeOS shows a real-time log stream — you can watch events happen live

AxeOS on the Bitaxe family is built on ESP-IDF (the ESP32 development framework), so the log format is different from Linux-based miners. Log entries include the ESP32 module name, log level, and message. For Bitaxe-specific log interpretation, see our Bitaxe Troubleshooting Guide.

Saving and Exporting Logs

Regardless of your miner platform, develop the habit of saving logs. Here are the methods:

Anatomy of a Kernel Log Entry

Before you can diagnose problems, you need to understand the structure of what you are reading. Every log entry follows a pattern, though the exact format varies by firmware. Here is the general anatomy:

[TIMESTAMP] [SOURCE/MODULE] [SEVERITY]: [MESSAGE]

Example (Antminer S19):
Jan 15 14:23:07 antMiner bmminer[1842]: Chain[0]: find 76 asic, times 0

Breaking this down:
  Jan 15 14:23:07    → Timestamp (date and time of the event)
  antMiner           → Hostname of the device
  bmminer[1842]      → Source module (bmminer) and process ID (1842)
  Chain[0]:          → Subsystem (hashboard chain 0)
  find 76 asic       → The actual message (76 ASIC chips detected)
  times 0            → Additional context (first detection attempt)

Timestamp Format

Timestamps vary by firmware:

Log Severity Levels

Not all log messages are created equal. The severity level tells you how urgently you need to pay attention:

In practice, stock Antminer firmware does not always tag messages with explicit severity labels the way a well-designed logging system would. You will often see raw messages without a [WARNING] or [ERROR] prefix — you learn the severity from the message content itself. Braiins OS and some aftermarket firmwares are better about this.

Source Modules

The source identifier tells you which component generated the message:

Normal Boot Sequence — What Healthy Looks Like

Before you can recognize what is wrong, you need to know what is right. A healthy ASIC miner boot follows a predictable sequence. Understanding this sequence means you can immediately spot where a troubled miner diverges from normal.

Boot Sequence Overview

Every ASIC miner goes through these phases during startup, in this order:

1. Linux Kernel Boot — CPU initialization, memory detection, driver loading, filesystem mount
2. Network Bring-Up — Ethernet interface activation, DHCP request, IP address assignment
3. Mining Software Start — bmminer/cgminer/btminer process launches
4. Hashboard Detection — Control board communicates with each hashboard via SPI/I2C, detects ASIC chips
5. ASIC Chip Enumeration — Each chip is addressed, tested, and configured with operating frequency and voltage
6. Frequency and Voltage Ramp — Chips start at low frequency and ramp up to target operating parameters
7. Pool Connection — Stratum connection established to configured mining pool
8. Mining Begins — First work units received, first shares computed and submitted

The full boot process typically takes 3 to 8 minutes depending on the miner model and chip count. Larger miners with more chips (like the S19j Pro with 504 chips) take longer to enumerate than simpler miners (like the S9 with 189 chips).

Annotated Healthy Boot Log (Antminer S19 Example)

Here is what a healthy boot looks like on an Antminer S19 series miner. We have annotated each phase so you know exactly what to expect. Your log will differ in specifics (timestamps, IP addresses, chip counts) but the pattern should match:

# ===== PHASE 1: LINUX KERNEL BOOT =====
[    0.000000] Linux version 4.6.0 (root@build-server) (gcc version 6.3.0)
[    0.000000] CPU: ARMv7 Processor rev 5 (v7l)
[    0.000000] Memory: 512MB
[    1.234567] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode
# HEALTHY: Kernel loads, CPU and memory detected, filesystem mounted

# ===== PHASE 2: NETWORK BRING-UP =====
Jan 15 00:00:05 antMiner daemon.notice netifd: Interface 'lan' is setting up
Jan 15 00:00:06 antMiner daemon.notice netifd: Network device 'eth0' link is up
Jan 15 00:00:08 antMiner daemon.notice netifd: Interface 'lan' has address 192.168.1.100/24
# HEALTHY: Ethernet link detected, DHCP assigns IP. Note the date may show
# Jan 1 if NTP has not synced yet — this is normal.

# ===== PHASE 3: MINING SOFTWARE START =====
Jan 15 00:00:15 antMiner user.notice bmminer: bmminer version 2.0.0 starting
Jan 15 00:00:15 antMiner user.notice bmminer: Initializing control board
Jan 15 00:00:16 antMiner user.notice bmminer: Loading configuration from /config/bmminer.conf
# HEALTHY: Mining software loads and reads configuration

# ===== PHASE 4: HASHBOARD DETECTION =====
Jan 15 00:00:20 antMiner user.notice bmminer: Chain[0]: Detected hashboard, sn: xxxxxxxxxxxx
Jan 15 00:00:21 antMiner user.notice bmminer: Chain[1]: Detected hashboard, sn: xxxxxxxxxxxx
Jan 15 00:00:22 antMiner user.notice bmminer: Chain[2]: Detected hashboard, sn: xxxxxxxxxxxx
# HEALTHY: All 3 hashboards detected (S19). For S19j Pro, expect Chain[0] through Chain[3].

# ===== PHASE 5: ASIC CHIP ENUMERATION =====
Jan 15 00:00:30 antMiner user.notice bmminer: Chain[0]: find 76 asic, times 0
Jan 15 00:00:35 antMiner user.notice bmminer: Chain[1]: find 76 asic, times 0
Jan 15 00:00:40 antMiner user.notice bmminer: Chain[2]: find 76 asic, times 0
# HEALTHY: Full chip count on every chain. S19 Pro = 76 chips/board.
# S19j Pro = 126 chips/board. S9 = 63 chips/board. S21 = 114 chips/board.

# ===== PHASE 6: FREQUENCY AND VOLTAGE RAMP =====
Jan 15 00:00:45 antMiner user.notice bmminer: Chain[0]: set frequency to 500
Jan 15 00:00:50 antMiner user.notice bmminer: Chain[0]: set voltage to 1250
Jan 15 00:01:00 antMiner user.notice bmminer: Chain[0]: ramping frequency 500 -> 600
Jan 15 00:01:30 antMiner user.notice bmminer: Chain[0]: target frequency reached: 600
# HEALTHY: Chips start at low frequency and ramp up. This is the miner
# stress-testing itself. The ramp takes 1-3 minutes per chain.

# ===== PHASE 7: POOL CONNECTION =====
Jan 15 00:02:00 antMiner user.notice bmminer: Pool 0: stratum+tcp://stratum.pool.com:3333
Jan 15 00:02:01 antMiner user.notice bmminer: Pool 0: Connected
Jan 15 00:02:01 antMiner user.notice bmminer: Pool 0: Authorized worker user.worker1
# HEALTHY: Pool connection established, worker authorized

# ===== PHASE 8: MINING BEGINS =====
Jan 15 00:02:05 antMiner user.notice bmminer: Pool 0: Received new work
Jan 15 00:02:06 antMiner user.notice bmminer: Accepted share: 00000000xxxxxxxx
Jan 15 00:02:10 antMiner user.notice bmminer: Hash rate: 95.2 TH/s
Jan 15 00:03:00 antMiner user.notice bmminer: Hash rate: 109.8 TH/s (ramping)
Jan 15 00:05:00 antMiner user.notice bmminer: Hash rate: 110.0 TH/s (stable)
# HEALTHY: Shares being accepted, hashrate ramping to target.
# Full hashrate is typically reached 3-8 minutes after boot.

# ===== ONGOING: NORMAL OPERATION =====
Jan 15 00:05:30 antMiner user.notice bmminer: Chain[0] Temp: chip=65 pcb=42
Jan 15 00:05:30 antMiner user.notice bmminer: Chain[1] Temp: chip=63 pcb=40
Jan 15 00:05:30 antMiner user.notice bmminer: Chain[2] Temp: chip=67 pcb=43
Jan 15 00:05:30 antMiner user.notice bmminer: Fan[0]: 4800 RPM
Jan 15 00:05:30 antMiner user.notice bmminer: Fan[1]: 4750 RPM
# HEALTHY: Temperatures 55-75°C chip, 35-50°C PCB. Fans spinning at expected RPM.

If your miner’s boot log matches this pattern — all chains detected, full chip counts, frequencies ramped to target, pool connected, shares accepted, temps and fans nominal — your miner is healthy. Bookmark this section and compare against it whenever you suspect a problem.

Critical Log Messages and What They Mean

This is the core of the guide — the error messages you will actually encounter, what they mean, and what to do about them. We have organized these by category, from the most common to the most obscure.

Chain / Hashboard Detection Errors

Hashboard detection errors are the most common and most impactful failures. If the control board cannot detect a hashboard, that hashboard produces zero hashrate. These errors appear during the boot sequence, in the chip enumeration phase.

“Chain[X]: find N asic, times 0” (Normal)

Chain[0]: find 76 asic, times 0
Chain[1]: find 76 asic, times 0
Chain[2]: find 76 asic, times 0

This is healthy. The control board found all expected ASIC chips on every chain. The times 0 means it succeeded on the first attempt. If you see times 1 or times 2, the control board had to retry detection — not necessarily a problem, but worth noting if it happens consistently.

“Chain[X]: find 0 asic” (Critical)

Chain[1]: find 0 asic, times 3
ERROR: Chain[1]: No hashboard detected after 3 attempts

This is critical. The control board cannot communicate with the hashboard at all. This hashboard is producing zero hashrate.

Possible causes (most to least likely):

1. Loose or damaged flat cable (ribbon cable) — The data cable between the control board and hashboard has come loose, corroded, or broken. This is the number one cause. Reseat both ends firmly.
2. Loose power connector — The hashboard is not receiving power. Check the power cable from the PSU to the hashboard.
3. Failed voltage regulator on the hashboard — The hashboard’s onboard power regulation circuitry has failed. The hashboard receives power but cannot distribute it to the chips. Requires board-level repair.
4. Damaged SPI/I2C bus — The communication bus between the control board and hashboard is damaged. Could be a broken trace on either board.
5. Dead hashboard — Multiple chips have failed catastrophically, preventing the chain from initializing. Requires professional repair or replacement.
6. Control board port failure — The specific connector on the control board is damaged. Test by swapping which hashboard is connected to which port.

“Chain[X]: find N asic” (Partial — Below Expected)

Chain[0]: find 76 asic, times 0    ← HEALTHY
Chain[1]: find 60 asic, times 2    ← PROBLEM: 16 chips missing
Chain[2]: find 76 asic, times 0    ← HEALTHY

This is degraded. The hashboard is communicating, but some chips are not responding. In this example, chain 1 is missing 16 of its 76 chips — approximately a 7% total hashrate loss from one board.

Possible causes:

1. Dead ASIC chips — Individual chips have failed. Common after power surges, overheating events, or age degradation.
2. Cold solder joints — Thermal cycling has cracked solder joints under chips, breaking electrical connection. May be intermittent.
3. Damaged signal traces — The SPI chain that daisy-connects chips is broken at a specific point, cutting off all chips downstream of the break.
4. Thermal paste degradation — Poor thermal contact causing localized overheating, which damages a cluster of chips.

Temperature and Thermal Errors

Thermal errors are the miner’s self-preservation system. ASIC chips operate within a strict temperature envelope — exceed it, and the firmware will throttle or shut down to prevent permanent damage.

“over max temp” / “DANGER: Temp Over Limit”

Chain[2] Temp: chip=95 pcb=68
WARNING: Chain[2] chip temperature above threshold (95 > 90)
DANGER: Chain[2] over max temp, shutting down chain
bmminer: All chains stopped due to thermal protection

This is critical — thermal shutdown. The miner detected chip temperatures exceeding the safe maximum (typically 90-95°C for chip temp) and shut down to prevent silicon damage.

Normal temperature ranges:

Fix steps:

1. Check ambient temperature. Is the room too hot? Is exhaust air recirculating back to the intake?
2. Verify all fans are spinning. A dead fan causes immediate temperature spikes on adjacent hashboards.
3. Clean dust from heatsinks and fan blades with compressed air.
4. Check that heatsinks are seated properly — they can shift during shipping or vibration.
5. Consider thermal paste replacement if the miner has been running for over 12 months.
6. If running a Bitcoin Space Heater or enclosed configuration, verify the ducting allows adequate airflow.

“temp sensor error” / “Chain[X] read temp failed”

Chain[0] Temp: chip=0 pcb=0
ERROR: Chain[0] temp sensor read failed
WARNING: Unable to read temperature, running in degraded mode

The temperature sensor on the hashboard cannot be read. The chip and PCB temperatures show as 0 or -1. This is dangerous because the miner cannot perform thermal protection — it may overheat without triggering shutdown.

Possible causes: Faulty temperature sensor IC on the hashboard, damaged sensor wiring, or flat cable connection issue affecting sensor data lines. This typically requires board-level repair — a technician needs to replace or reflow the temperature sensor IC.

ASIC Chip Errors

“nonce error” / “HW Error”

Chain[1] nonce error: chip 42, core 3
Chain[1] HW errors: 127 in last 60s
WARNING: Chain[1] hardware error rate exceeds threshold (2.1%)

A nonce error (also called a hardware error, or “HW error”) means an ASIC chip returned an incorrect computation result. The chip attempted to hash a block header, found what it thought was a valid nonce, but the result failed the verification check. Think of it as a math error — the chip gave the wrong answer.

Some HW errors are normal. Even healthy miners produce occasional nonce errors due to silicon imperfections, voltage fluctuations, and cosmic rays (seriously). The key metric is the error rate:

“chip X disabled” / “asic ID error”

Chain[2] chip 18: asic ID error, disabling
Chain[2] chip 19: asic ID error, disabling
Chain[2]: 2 chips disabled, running with 74 of 76

The firmware detected that specific chips are not responding to communication attempts and has disabled them. The miner continues running with reduced capacity. An asic ID error means the control board sent an address command to a specific chip and got no response or a corrupted response — the chip is either dead or has a broken communication path.

“freq adjust” / Frequency Down-Regulation

Chain[0]: chip temp high, reducing frequency 600 -> 550
Chain[0]: freq adjust: 550 MHz (was 600 MHz) — thermal throttle
Chain[0]: hashrate reduced to ~95 TH/s (target: 110 TH/s)

The firmware is throttling — reducing operating frequency to lower temperature or compensate for errors. This is a protective mechanism, not a failure. However, persistent throttling means something is wrong: inadequate cooling, high ambient temperature, or degraded thermal paste preventing proper heat transfer.

Power Errors

“voltage too low” / “voltage too high” / “V_IN abnormal”

ERROR: Chain[0] voltage too low: 1180 mV (expected 1250 mV)
ERROR: V_IN abnormal: 11.2V (expected 12.0V)
WARNING: PSU voltage drop detected, check power connections
CRITICAL: Chain[0] power off — voltage protection triggered

Voltage errors are dangerous. Under-voltage can cause chips to produce incorrect computations or fail to initialize. Over-voltage can physically damage chips. These errors typically indicate:

1. PSU failure or degradation — The power supply cannot maintain stable output under load. PSU capacitors degrade over time, especially in hot environments.
2. Loose power connectors — High-current connections develop resistance at the plug, causing voltage drop. Reseat all power connectors firmly.
3. Undersized wiring — If the miner is fed through extension cords or undersized wire gauge, voltage drops under load.
4. Input voltage problem — Wall voltage too low (brownout condition) or unstable. Measure at the outlet with a multimeter under load.
5. Failed voltage regulator on hashboard — The onboard boost/buck converter that regulates chip voltage has failed. Requires board-level repair.

Pool Connection Errors

“stratum connection” / Pool Connect and Disconnect

# Normal connection:
Pool 0: stratum+tcp://stratum.pool.com:3333 connected
Pool 0: Authorized worker miner1.worker1
Pool 0: Received work, diff 65536

# Connection failure:
Pool 0: socket connect failed to stratum.pool.com:3333
Pool 0: Retry in 15 seconds
Pool 0: socket connect failed to stratum.pool.com:3333
Pool 0: Switching to Pool 1 (backup)
Pool 1: stratum+tcp://backup.pool.com:3333 connected

# Connection timeout:
Pool 0: Stratum connection timeout (no data received for 120s)
Pool 0: Reconnecting...

Pool connection events are normal during operation. Pools restart, connections rotate, and brief disconnections happen. The concern is when you see repeated failures across all configured pools — this indicates a network problem on your end, not a pool problem.

“Rejected share” / Share Rejections

Pool 0: Accepted share 14523 diff 65536
Pool 0: Rejected share 14524: stale
Pool 0: Rejected share 14530: duplicate
Pool 0: Rejected share 14535: low difficulty

Share rejections have specific reasons:

• Stale — The share was valid but the pool already moved to a new block template. Caused by high network latency or slow pool response. A stale rate under 1-2% is normal.
• Duplicate — The same share was submitted twice. Usually a software glitch or network hiccup causing a retransmission.
• Low difficulty — The share does not meet the minimum difficulty set by the pool. May indicate a firmware bug or misconfigured pool settings.
• Above target / Invalid — The share’s hash does not actually meet the claimed difficulty. If frequent, this suggests hardware errors (bad nonce computation) — see nonce errors.

Fan Errors

“fan error” / “fan speed error” / “fan lost”

# Normal fan readings:
Fan[0]: 5200 RPM  Fan[1]: 5150 RPM  Fan[2]: 4900 RPM  Fan[3]: 5050 RPM

# Fan failure:
ERROR: Fan[2]: speed 0 RPM (expected >1000 RPM)
ERROR: Fan[2] lost — fan not detected
CRITICAL: Fan speed below minimum threshold, shutting down for protection

Fan errors trigger immediate protective shutdown on most firmware versions. ASIC miners generate extreme heat density — a single dead fan can cause a hashboard to overheat within seconds.

Common causes:

1. Fan motor failure — Bearings worn out, winding burned. Replace the fan.
2. Loose fan connector — The 4-pin fan header has vibrated loose. Reseat it firmly.
3. Blocked fan — Dust buildup, debris, or a loose cable physically blocking the fan blade.
4. PWM control board failure — The fan speed controller on the control board has failed (rare, but we have seen it).

If your miner shuts down with a fan error but all fans appear to be spinning, check the RPM sense wire (the third wire in the fan connector). A fan can spin but fail to report its speed if the tachometer wire is broken.

Diagnostic Decision Trees

When your miner has a problem, start with the symptom and follow the log evidence. Here are the four most common scenarios and the systematic log-based approach to diagnosing them.

Scenario: Hashboard Not Detected

Symptom: Dashboard shows only 2 of 3 hashboards (or 3 of 4). Hashrate is significantly below target.

Step 1: Check the kernel log for the chain detection phase. Look for:

cat /var/log/messages | grep -i "chain|find.*asic"

• If you see find 0 asic on the missing chain → communication failure. Reseat flat cable. Swap flat cables between working and non-working chains to isolate cable vs. port vs. board.
• If the chain does not appear in the log at all → power delivery failure. The hashboard is not powering on. Check the power connector from PSU to that hashboard.
• If you see EEPROM read failed → EEPROM chip failure on the hashboard. The identification chip is damaged. Professional repair required.

Step 2: Swap test. Move the suspect hashboard to a different chain port. If the problem follows the board, the board is faulty. If the problem stays on the port, the control board port or cable is faulty.

Scenario: Low Hashrate

Symptom: All hashboards detected, but total hashrate is 10-30% below expected.

Step 1: Check chip counts. A partial chip count is the most common cause of low hashrate with all boards detected.

cat /var/log/messages | grep -i "find.*asic|freq|frequency"

• If chip counts are below expected → Dead chips. See partial chip count section.
• If chip counts are correct but frequency is reduced → Thermal throttling. Check temperatures.
• If chip counts and frequency are normal → Check HW error rate. High error rates waste hashrate on incorrect computations.

Step 2: Check temperatures across all chains. Look for one chain significantly hotter than others — this indicates a localized cooling problem (dusty heatsink, failed thermal paste, blocked airflow).

Step 3: Check pool-side stats. Compare the miner’s reported hashrate to the pool’s reported hashrate. A significant discrepancy (miner reports 100 TH/s but pool sees 80 TH/s) suggests high share rejection rates — check network connectivity and stale share counts.

Scenario: Miner Keeps Restarting

Symptom: Miner boots, runs briefly (seconds to minutes), then restarts. May be in a boot loop.

Step 1: Save the log immediately after a restart — before it reboots again. Look at the last 50 lines before the restart:

tail -50 /var/log/messages

• If the last lines show over max temp → Thermal shutdown with auto-restart. Fix cooling.
• If the last lines show power fault or V_IN abnormal → PSU problem. Miner draws power, voltage drops, protection triggers, miner restarts, cycle repeats.
• If the last lines show fan lost → Fan failure triggering protective restart.
• If the last lines show cgminer not running or bmminer: Segmentation fault → Mining software crash. Firmware corruption is likely. Reflash firmware.
• If the log simply ends mid-sentence with no error → Hard power cut. The PSU is cutting out under load. Test PSU with a known-good unit.

Scenario: High Error Rate

Symptom: Hashrate looks normal on the dashboard, but the pool reports lower effective hashrate. Or: the miner web interface shows high “HW” error counts.

Step 1: Quantify the error rate from the log:

cat /var/log/messages | grep -i "nonce error|hw error|hardware error"

• If errors are concentrated on one chain → That hashboard has failing chips. The other boards are healthy.
• If errors are spread across all chains → Systemic issue. Check voltage (PSU), temperature (cooling), or firmware (update or reflash).
• If errors spike at specific times → Environmental factor. Correlate with temperature changes (afternoon heat), power events (other equipment cycling on/off), or network issues.

Step 2: If your firmware supports per-chip error reporting, identify the specific chip numbers producing errors. A cluster of adjacent bad chips suggests a localized board problem (cold solder, damaged trace). Scattered bad chips suggest voltage or thermal stress.

Log Analysis for Different Miner Models

While the concepts are universal, the specific log format and common patterns differ between miner generations and manufacturers. Here are the key differences you need to know.

Antminer S9 Log Format

The S9 runs cgminer (or bmminer, which is Bitmain’s fork of cgminer). Log output is relatively simple and well-documented due to the S9’s long production run and massive user base.

Antminer S17/T17 Log Format

The S17 generation introduced Bitmain’s BHB (Bitmain Hash Board) communication protocol and a more complex logging system. These miners are more verbose in their logs.

Antminer S19 Log Format

The S19 series uses bmminer with the BHB protocol. Logs are more structured and include additional diagnostics compared to older generations.

Whatsminer Log Format

Whatsminer logs use a different structure than Antminer. The mining software is btminer (MicroBT’s proprietary daemon), and it uses different terminology for similar concepts.

Whatsminers also log per-hashboard power consumption, which is extremely useful for diagnostics. A hashboard drawing significantly more or less power than its siblings indicates a voltage regulation issue or chip failures on that specific board.

Advanced Log Analysis

Once you are comfortable reading individual log entries, these advanced techniques help you analyze patterns across large volumes of log data. This is how D-Central’s repair technicians work — we do not just read logs, we interrogate them.

Filtering Logs with grep

The grep command is your scalpel. Instead of reading thousands of lines, extract exactly what you need:

# Show ONLY error and critical messages
cat /var/log/messages | grep -i "error|fail|critical|fault|danger"

# Show all chain/hashboard events
cat /var/log/messages | grep -i "chain|hashboard|asic"

# Show all temperature readings (great for spotting trends)
cat /var/log/messages | grep -i "temp"

# Show all fan-related events
cat /var/log/messages | grep -i "fan"

# Show all pool/stratum events
cat /var/log/messages | grep -i "pool|stratum|share|connect"

# Show all voltage/power events
cat /var/log/messages | grep -i "volt|power|v_in|psu"

# Show events for a SPECIFIC chain only
cat /var/log/messages | grep -i "chain[1]"

# Count how many errors occurred (gives you a number)
cat /var/log/messages | grep -ci "error"

# Show errors with 3 lines of context (before and after)
cat /var/log/messages | grep -i -B3 -A3 "error"

# Show the LAST 100 lines (most recent events)
tail -100 /var/log/messages

# Combine filters: errors on chain 2 only
cat /var/log/messages | grep -i "chain[2]" | grep -i "error"

Calculating ASIC Error Rate from Logs

If your firmware does not display a clean error rate percentage, you can calculate it from log data. The formula is:

HW Error Rate = (HW Errors / Total Shares Computed) × 100%

To get these numbers from the log:

# Count accepted shares
cat /var/log/messages | grep -ci "accepted"

# Count hardware errors
cat /var/log/messages | grep -ci "nonce error|hw error"

# Example: 15,000 accepted shares, 45 HW errors
# Error rate = 45 / 15,000 = 0.3% — HEALTHY

Temperature Trending

Pulling all temperature readings and looking at the pattern over time reveals cooling problems before they cause shutdowns:

# Extract all temperature readings with timestamps
cat /var/log/messages | grep -i "temp" | tail -50

# Example output showing a problem developing:
# 14:00:05 Chain[2] Temp: chip=62 pcb=40   ← Normal
# 14:30:05 Chain[2] Temp: chip=65 pcb=42   ← Normal
# 15:00:05 Chain[2] Temp: chip=71 pcb=47   ← Warming up
# 15:30:05 Chain[2] Temp: chip=78 pcb=53   ← Getting hot
# 16:00:05 Chain[2] Temp: chip=84 pcb=59   ← WARNING zone
# 16:15:05 Chain[2] Temp: chip=89 pcb=63   ← About to throttle
# 16:20:05 Chain[2] freq adjust: 600 -> 520 ← Throttling started
# 16:30:05 DANGER: Chain[2] over max temp   ← Shutdown

This pattern — a slow temperature climb over hours — typically indicates dust accumulation, failing thermal paste, or rising ambient temperature. The fix is physical: clean, re-paste, or improve ventilation.

When Logs Indicate Repair vs. Replacement

Sharing Logs with D-Central Support

When you contact D-Central for support or repair, providing a complete kernel log dramatically accelerates diagnosis. Here is how to give our technicians exactly what they need.

How to Export Your Logs

1. Web Interface: Go to System → Kernel Log. Select all text (Ctrl+A), copy (Ctrl+C), paste into a text file. Save as miner_log_YYYY-MM-DD.txt.
2. SSH: Run cat /var/log/messages > /tmp/full_log.txt, then use SCP to transfer: scp root@MINER_IP:/tmp/full_log.txt ./miner_log.txt
3. Screenshot: If SSH and web copy are not available, a clear screenshot of the log viewer (especially the last 50 lines) is better than nothing.

What to Include in a Support Ticket

What D-Central’s Technicians Look For

When a kernel log arrives at our repair desk, our technicians follow a systematic analysis process:

1. Boot sequence check — Did all boards detect? Full chip counts? Any EEPROM or PIC errors?
2. Error pattern analysis — Are errors concentrated on one chain or spread across all? Concentrated errors point to a specific board. Distributed errors suggest PSU or environmental issues.
3. Temporal analysis — When did errors start? Did they coincide with temperature changes, power events, or firmware updates?
4. Rate of degradation — Is the problem stable (same 3 chips missing every boot) or progressive (losing more chips each week)? Progressive failure needs urgent attention.
5. Correlation check — Do temperature readings correlate with errors? Do voltage readings correlate with chip losses? These correlations reveal root cause.

Frequently Asked Questions

When to Contact D-Central

This guide gives you the knowledge to diagnose most ASIC miner issues from the kernel log alone. But some problems require professional tools, professional skills, and professional equipment. Here is when to stop troubleshooting and call in the experts:

• Hashboard consistently shows 0 chips after reseating all cables and swap-testing — the board has a hardware failure.
• Progressive chip loss — you are losing more chips each week. The board is degrading and needs component-level repair before total failure.
• Voltage regulator errors — the log shows voltage faults that are not resolved by changing the PSU. The onboard power regulation has failed.
• EEPROM/PIC failures — the identification chip needs reprogramming or replacement.
• Physical damage — burn marks, corrosion, or visible component damage on the hashboard.
• You have identified the problem but do not have the tools or experience for component-level repair — soldering BGA ASIC chips requires a rework station, stencils, and practice.

Reading kernel logs is a skill. Like any skill, it improves with practice. Save every log you pull, even from healthy boots — over time, you will build an intuitive sense of what normal looks like for each of your miners, and you will catch problems earlier because of it. Every hash counts, and every log entry tells a story. Learn to read the story, and you become a better miner.

D-Central Technologies — Bitcoin Mining Hackers since 2016. We are the North.