Complete Antminer Error Code Reference: Every Error Message Explained

How to Read This Guide

This reference manual is your field handbook for diagnosing Antminer issues. Whether you are staring at a blinking red LED at 2 AM or parsing cryptic kernel log messages over SSH, this guide will tell you exactly what is happening and what to do about it.

The guide is organized by error category — LED indicators, kernel log messages, network issues, hashboard errors, temperature faults, power supply problems, ASIC chip failures, and firmware issues. Each error entry follows a consistent format:

Throughout the guide, error codes and technical values are displayed in monospace orange, healthy/normal values in green, and critical/error values in red.

Model-specific notes are called out where the S9, S17, S19, and S21 series behave differently. If your model is not listed, the guidance usually applies to miners in the same generation (SHA-256 Antminers sharing the same control board architecture).

LED Status Indicators

Every Antminer control board has status LEDs — small surface-mount indicators that give you an immediate visual read on the miner’s state before you ever open a terminal. Learning to read them is the fastest way to triage a problem.

The LED configuration varies by model generation. The S9 has a simple green/red pair. The S17 and S19 series introduced a third amber/yellow indicator. The S21 series uses a similar tri-color scheme. Regardless of model, the logic is consistent: green = operating, red = fault, amber = warning or transitional state.

Green LED (Normal Operation)

If the green LED is solid and the miner dashboard shows all chains hashing at expected rates, your miner is healthy. On the S9, expect to see 3 chains detected. On the S19 and S21 series, expect 3 hashboards with all ASIC chips reporting in.

Red LED (Error State)

A solid red LED demands immediate attention. Power cycle the miner, wait 30 seconds, then power on. If the red LED returns within 60 seconds of boot, the issue is hardware-level — check hashboard connectors, PSU voltage, and ambient temperature before proceeding to the relevant error section below.

Yellow/Amber LED (Warning)

The amber LED appears on S17, S19, and S21 series control boards. It indicates a degraded but not fully failed state.

LED Flash Patterns

Some Antminer models encode specific errors into LED blink sequences. Here are the most common patterns across generations:

Kernel Log Error Codes

The kernel log is the most detailed diagnostic source on any Antminer. It records every event from hashboard initialization to chip-level communication failures. Access it via SSH or through the miner’s web interface under “System Log” or “Kernel Log.”

Here is how to pull the kernel log via SSH:

# SSH into the miner (default credentials: root / root)
ssh root@MINER_IP

# View the full kernel log
dmesg

# Or view the miner-specific log (path varies by firmware)
cat /var/log/messages | grep -i "bitmain|chain|hashboard|error|fault"

# On S19/S21 with newer firmware:
cat /tmp/log/bmminer.log

Below are the most common kernel log error strings you will encounter. Each entry links to its detailed section in this guide.

Network & Connection Errors

Network errors prevent your miner from communicating with the mining pool. The miner may be hashing locally but submitting zero shares — which means zero revenue. These errors are often the easiest to fix, since they are usually caused by network configuration rather than hardware failure.

“socket connect failed”

What it means: The miner’s mining software (cgminer, bmminer, or bosminer) cannot establish a TCP connection to the pool server on the configured port.

Possible causes (most to least likely):

1. Incorrect pool URL or port number in miner configuration
2. Internet connection down — Ethernet cable unplugged or router issue
3. Pool server is temporarily offline or under maintenance
4. Firewall or router blocking outbound connections on the pool’s port (commonly 3333, 25, or 443)
5. DNS resolution failure (see DNS Resolve Failed)
6. Miner’s Ethernet port hardware failure (rare)

Fix steps:

1. Verify the pool URL and port in Miner Configuration > Pool Settings. Common format: stratum+tcp://pool.example.com:3333
2. Check that the Ethernet cable is securely seated on both ends (miner and switch/router). Try a different cable.
3. Verify internet connectivity: SSH into the miner and run ping 8.8.8.8. If this fails, the issue is network-layer, not pool-layer.
4. Try your backup pool URL. If the backup connects, the primary pool may be down.
5. Check your router for any port-blocking rules. Some ISPs block non-standard ports — try a pool endpoint on port 443 (SSL) as a workaround.
6. If using a managed switch, verify the miner’s port has link status.

“Stratum connection interrupted”

What it means: The miner had an active connection to the pool, but the connection dropped. This is different from socket connect failed — the initial connection succeeded, but the ongoing session was disrupted.

Possible causes:

1. Intermittent internet connectivity (packet loss, flapping Ethernet link)
2. Pool server restarted or rotated backend nodes
3. Router or modem reboot
4. DHCP lease expiration causing brief network interruption
5. ISP-level routing change

Fix steps:

1. If the miner reconnects within 30–60 seconds, this is normal pool behavior. Most pools cycle connections periodically.
2. If interruptions are frequent (multiple per hour), check your network stability: SSH in and run ping -c 100 8.8.8.8 and look for packet loss above 1%.
3. Assign a static IP to the miner to avoid DHCP conflicts. Configure this in your router’s DHCP reservation table.
4. Ensure your miner has all three pool slots configured (Pool 1, Pool 2, Pool 3) so it can failover automatically.
5. Check cable quality — Cat5e or better is required. Cat6 is recommended for runs over 10 meters.

“DNS resolve failed”

What it means: The miner cannot translate the pool’s domain name (e.g., stratum.slushpool.com) into an IP address.

Possible causes:

1. DNS server not configured or unreachable
2. Typo in pool URL
3. Router’s DNS relay is failing
4. ISP DNS outage

Fix steps:

1. SSH into the miner and test DNS: nslookup stratum.slushpool.com
2. If DNS fails, try setting a public DNS server. Edit /etc/resolv.conf and add: nameserver 8.8.8.8 and nameserver 1.1.1.1
3. Alternatively, use the pool’s IP address directly in the pool URL instead of the domain name (check the pool’s documentation for their IP)
4. Restart the miner’s network stack: /etc/init.d/network restart

Hashboard Detection Errors

Hashboard detection errors are among the most common and most consequential issues. A missing hashboard means you are losing one-third (or more) of your hash rate. These errors appear during the miner’s initialization sequence when the control board attempts to communicate with each hashboard over the SPI/I2C bus.

“Chain[X] only has Y chips”

What it means: Hashboard X was detected, but not all ASIC chips on the board responded during initialization. The miner expected a full chip count but found fewer.

Possible causes:

1. Loose flat cable (ribbon cable) — The most common cause. The flat cable connecting the hashboard to the control board is not fully seated or has a damaged pin.
2. Dead ASIC chip(s) — One or more chips on the hashboard have failed, breaking the daisy chain.
3. Corroded or dirty connector — Dust, humidity, or thermal cycling has degraded the connection.
4. Damaged PCB trace — Physical damage to the hashboard’s signal traces.
5. Incompatible firmware — Firmware expecting a different chip count than installed hardware.

Fix steps:

1. Reseat flat cables: Power off. Remove and firmly reinsert the flat ribbon cable on both ends (hashboard side and control board side). Ensure the locking tab clicks into place.
2. Swap flat cables: Try a known-good flat cable. These cables are fragile and develop intermittent faults.
3. Isolate the board: If you have three hashboards and only one is short on chips, try that board in a different slot on the control board. If the fault follows the board, the issue is on the hashboard itself.
4. Visual inspection: Open the miner and inspect the hashboard for burnt components, bulging capacitors, solder cracks around BGA chips, or physical damage.
5. If visual inspection reveals burn marks or dead chips, the hashboard needs professional repair — individual ASIC chip replacement requires BGA rework equipment.

“No hashboard found”

What it means: The control board completed its initialization scan and could not detect any hashboard on any chain. This is a complete communication failure.

Possible causes:

1. PSU not powering the hashboards — The control board is powered (you can access the web UI) but the hashboard power connectors are disconnected or the PSU output is dead.
2. All flat cables disconnected or damaged
3. Control board failure — The SPI bus on the control board is dead.
4. Firmware corruption — Mining daemon cannot initialize the driver.
5. Blown fuse on hashboard power input (common on S17 series)

Fix steps:

1. Verify PSU output: Use a multimeter to confirm the PSU is delivering 12.0V–12.6V at the hashboard power connectors.
2. Check all power and data cable connections between PSU, control board, and hashboards.
3. Try connecting just one hashboard at a time to isolate whether the issue is a specific board or the control board.
4. If a single board is detected when isolated but not with all three connected, suspect PSU capacity — it may not have enough current output for a full load.
5. Flash stock firmware via SD card to rule out software issues (see SD Card Boot Issues).
6. If no hashboard is detected even with fresh firmware and verified power, the control board likely needs replacement.

“EEPROM read failed”

What it means: Each hashboard has a small EEPROM chip that stores identification data — serial number, chip configuration, and voltage settings. When the control board cannot read this chip, it refuses to initialize the hashboard.

Possible causes:

1. Loose or damaged data cable (I2C line is separate from the SPI chain on some models)
2. EEPROM chip damaged or desoldered from the PCB
3. Corrupted EEPROM data (power loss during a firmware configuration write)
4. Incompatible firmware for the hashboard revision

Fix steps:

1. Reseat the flat cable. The EEPROM data line is carried on the same flat cable on most models.
2. Try the hashboard in a different control board slot.
3. On S9: The EEPROM is a small 8-pin chip near the flat cable connector. Inspect for damage. A replacement EEPROM can be programmed and soldered by a repair technician.
4. On S17/S19/S21: EEPROM failures often indicate deeper board issues. Professional diagnosis is recommended.
5. Flash the stock firmware for your exact hardware revision. Mismatched firmware can cause EEPROM read failures even when the chip is healthy.

Temperature & Fan Errors

Thermal protection is the miner’s self-preservation system. When temperatures exceed safe limits or fan speed drops below minimum, the miner will throttle or shut down to prevent permanent chip damage. These are the most common errors for home miners — because home environments are not data centers.

“over max temp” / Temperature Protection

What it means: One or more temperature sensors on a hashboard reported a reading above the firmware’s configured maximum. The miner has halted hashing on the affected chain (or the entire machine) to prevent thermal damage.

Possible causes:

1. High ambient temperature — Room temperature above 35°C (95°F) will push chip temps past limits under full load.
2. Blocked airflow — Miner placed against a wall, intake/exhaust obstructed, dust buildup on heatsinks.
3. Fan failure — One or more fans dead or spinning below rated speed.
4. Thermal paste degradation — On S17 and newer with heatsink-to-chip thermal paste, dried or cracked paste increases thermal resistance dramatically.
5. Overclocking — Running above stock frequency generates more heat than the cooling system can handle.
6. Faulty temperature sensor — A sensor reading artificially high (less common but possible).

Fix steps:

1. Immediate: Allow the miner to cool down for 15–30 minutes before restarting.
2. Check ambient temperature. For reliable operation, keep room temperature below 30°C (86°F). Canadian basements are ideal.
3. Ensure at least 30 cm (12 inches) of clearance on both intake and exhaust sides of the miner.
4. Inspect and clean fans. Compressed air removes dust from heatsinks and fan blades.
5. Check that all fans are spinning and at expected RPM (see Fan Speed Errors).
6. For S17/S19/S21: If the miner overheats with clean fans and good airflow, the thermal paste between ASIC chips and heatsinks may need replacement. This requires disassembling the hashboard.
7. If overclocked, return to stock frequency settings and test again.

“fan lost” / Fan Speed Errors

What it means: The control board monitors fan tachometer signals. If a fan’s reported RPM drops below the minimum threshold (typically 1000 RPM on most models), or the tachometer signal disappears entirely, the miner flags the error. Most models will halt hashing to prevent overheating.

Possible causes:

1. Fan cable disconnected — The 4-pin fan connector is not seated properly on the control board.
2. Fan bearing failure — The fan motor is seized or grinding. Often preceded by unusual noise.
3. Fan PCB fault — The tachometer circuit on the fan has failed. The fan may still spin but cannot report speed.
4. Foreign object blockage — A zip tie, wire, or debris caught in the fan blades.
5. Control board fan header damage — The 4-pin header on the control board is loose or burned.

Fix steps:

1. Power off. Visually inspect all fans for obstructions and free movement (spin by hand).
2. Reseat all fan connectors on the control board.
3. Swap the suspected fan with a known-good fan from the other end of the miner. If the error follows the fan, the fan is dead and needs replacement.
4. S9 fans are standard 120mm 4-pin PWM fans and are inexpensive to replace. S19/S21 use proprietary fans specific to the model — use the correct replacement.
5. Check if the fan spins but reports 0 RPM — this means the tachometer wire is broken. Replace the fan.

“PCB temp too high”

What it means: The PCB-level temperature sensor (measuring the circuit board surface, not the ASIC chip directly) is reading above its threshold. This is distinct from over max temp (which measures chip junction temperature). PCB temp too high usually indicates an environmental or airflow problem rather than a specific component failure.

Possible causes:

1. Insufficient exhaust — hot air recirculating back into the intake
2. Multiple miners in a confined space without adequate ventilation
3. Dust insulating the PCB surface
4. Ambient temperature too high for the cooling capacity

Fix steps:

1. Separate intake and exhaust airflows. Use ducting if miners are in a small room.
2. Clean the interior of the miner with compressed air, focusing on the PCB surfaces and heatsink fins.
3. Reduce ambient temperature or add supplemental cooling (inline fan on exhaust duct).
4. If using miners as space heaters, ensure the room has adequate ventilation so recirculated heat does not push PCB temps past limits.

Power Supply Errors

The PSU is the heart of your mining operation. An undersized, aging, or failing PSU will cause a cascade of downstream errors — hashboard detection failures, temperature issues (from voltage sag causing chips to work harder), and intermittent reboots. Many errors attributed to hashboards or firmware are actually PSU issues.

“Power fault” / “V_IN abnormal”

What it means: The control board’s voltage monitoring circuit detected that the input voltage from the PSU is outside the acceptable range. This can mean overvoltage, undervoltage, or high ripple.

Possible causes:

1. PSU output voltage drift — An aging PSU may drift below 11.8V or above 13.0V under load.
2. Loose power connectors — High-current connections develop resistance at loose contacts, causing voltage drop.
3. Wall outlet voltage sag — Running on a circuit shared with other high-draw appliances (dryers, air conditioners).
4. PSU overload — Using a PSU rated below the miner’s maximum power draw.
5. Corroded power connectors — Oxidation on the 6-pin PCIe-style connectors increases resistance.

Fix steps:

1. Measure PSU output: With the miner running, use a multimeter on the hashboard power connectors. Healthy range is 12.0V–12.6V. Below 11.8V or above 13.2V indicates a problem.
2. Reseat all power connectors firmly. Wiggle each connector while the miner is running — if hash rate dips or the miner reboots, that connection is the culprit.
3. Ensure the PSU is rated for the miner’s consumption with at least 10% headroom. An S19 Pro pulling 3250W needs a 3600W+ PSU.
4. Check the wall outlet with a multimeter. In North America, you should see 240V ±5% on a dedicated 30A circuit for large miners, or 120V ±5% for S9-class units.
5. If the PSU output is sagging under load, the PSU is aging and needs replacement. Running a miner on a weak PSU can damage hashboards.

Voltage Out of Range

What it means: On S17, S19, and S21 series, each hashboard has individual voltage regulators (voltage domains) that step down the 12V input to the chip-level operating voltage (typically 0.3V–0.5V per domain, depending on the chip generation). The voltage out of range error means one or more of these on-board regulators is not hitting its target voltage.

Possible causes:

1. Failed voltage regulator (MOSFET or buck converter) on the hashboard
2. Shorted ASIC chip pulling the voltage domain down
3. PSU unable to deliver clean 12V (ripple or sag causing the on-board regulators to fault)
4. Damaged PCB trace in the power delivery network

Fix steps:

1. First, rule out the PSU by testing with a known-good power supply.
2. Check the miner’s web dashboard for per-domain voltage readings. Any domain showing 0.000V or significantly lower than its neighbors has a local failure.
3. If a single domain is affected, the hashboard needs professional repair — the voltage regulator circuit or a shorted ASIC chip in that domain must be identified and replaced with proper SMD/BGA rework equipment.

ASIC Chip Errors

ASIC chip errors are the granular level of failure — individual silicon dies on the hashboard that are malfunctioning. Modern hashboards contain 63 to 126+ chips, each independently addressable. When a chip fails, it affects the entire chain’s performance because chips are wired in a serial communication daisy chain.

“chip X disabled”

What it means: The mining firmware identified ASIC chip number X as non-functional and removed it from the work distribution. The chip is not responding to commands, producing no valid nonces, or returning only errors.

Possible causes:

1. Dead ASIC chip — The silicon has failed permanently. Causes include thermal stress, manufacturing defect, or electrical damage (power surge, ESD).
2. Bad solder joint — The BGA (ball grid array) connection between the ASIC chip and the PCB has fractured. This can happen from thermal cycling (repeated heat/cool cycles).
3. Insufficient cooling on that chip — A localized thermal paste void causing one chip to overheat and shut down while neighbors are fine.
4. Damaged trace or via — A PCB interconnect feeding that specific chip is broken.

Fix steps:

1. Note which chip number is disabled. If only 1–2 chips are disabled out of the full board, the miner will continue operating at reduced hash rate. Monitor whether additional chips begin failing.
2. Check the temperature readings for the affected chain. A hot spot near the disabled chip suggests a localized cooling problem — clean heatsinks and reapply thermal paste.
3. If the disabled chip count is increasing over time, the board is developing cascading failures. Get it repaired before more chips die.
4. Individual ASIC chip replacement is a professional-level repair requiring a BGA rework station, flux, and replacement chips. This is D-Central’s specialty — we have replaced thousands of individual ASIC chips since 2016.

“nonce error” / High Reject Rate

What it means: A nonce is the value that miners iterate to find valid block hashes. A nonce error means a chip returned a nonce that the control board verified as incorrect — the chip “thinks” it found a valid hash, but the control board’s recheck shows it is wrong. A low rate of nonce errors is normal (hardware error rate or HW errors). A high rate indicates a chip computing incorrectly.

Healthy vs. unhealthy HW error rates:

• 0–0.01% HW error rate — Normal operation
• 0.01–0.1% HW error rate — Slightly elevated, monitor the trend
• >0.1% HW error rate — Problematic. Chips are producing garbage. Investigate.

Possible causes:

1. Overclocking beyond chip stability — The chip is running faster than it can reliably compute.
2. Voltage too low for the set frequency — Undervolting too aggressively causes computation errors.
3. Degraded or dying chip — A chip nearing end of life will produce increasing nonce errors before fully failing.
4. Thermal throttling — Chip overheating causes computational errors before triggering a full thermal shutdown.
5. PSU ripple — Noisy power delivery causes transient voltage fluctuations that corrupt chip operations.

Fix steps:

1. If overclocked, reduce frequency to stock settings and test. If HW errors drop to near zero, your overclock was too aggressive.
2. If running at stock, check temperatures. A chip running at 85°C+ will produce more errors than one at 65°C.
3. Check PSU health and connectors (see Power Supply Errors).
4. If HW errors are concentrated on one chain, the issue is hashboard-specific. Try that board with a different PSU to rule out power delivery.
5. If the problem persists at stock settings with good power and cooling, the hashboard has failing chips and needs professional repair.

“chip bin not found”

What it means: “Chip bin” refers to the performance classification data for the ASIC chips. Each chip is binned during manufacturing based on its performance characteristics. If the firmware cannot find valid bin data, it does not know how to set the correct voltage and frequency for the chips on that hashboard.

Possible causes:

1. EEPROM corruption — The chip bin data is stored in the hashboard’s EEPROM. See EEPROM Read Failed.
2. Firmware mismatch — The installed firmware does not match the hashboard hardware revision. This commonly happens when third-party firmware is flashed on incompatible hardware.
3. Hashboard replaced with wrong revision — Mixing hashboard revisions in the same miner can cause bin lookup failures.

Fix steps:

1. Flash the official Bitmain firmware for your exact model and hardware revision.
2. If using custom firmware (e.g., Braiins OS, Vnish), verify it supports your specific hardware revision. Check firmware release notes.
3. Verify all three hashboards are the same hardware revision. Mixed boards are not supported on most models.
4. If the EEPROM needs reprogramming, this requires reading the chip data from a working board of the same type and writing it to the failed board — a repair shop procedure.

Firmware & Software Errors

Firmware errors range from minor annoyances to bricked miners. The mining firmware controls every aspect of hardware operation — chip initialization, voltage regulation, temperature monitoring, pool communication. When it fails, the miner may refuse to boot, crash repeatedly, or operate erratically.

“cgminer not running”

What it means: The mining daemon (cgminer, bmminer, or bosminer, depending on firmware) has crashed, failed to start, or was killed by the system. The web interface may be accessible, but no mining is happening.

Possible causes:

1. Configuration error — Invalid pool URL, malformed worker name, or corrupt config file.
2. Hardware fault — The mining daemon crashed because it could not initialize a hashboard (the real error is hardware, not software).
3. Memory corruption — NAND flash degradation on older miners (especially S9 with thousands of power cycles).
4. Incompatible firmware — Third-party firmware for the wrong hardware revision.
5. Overclocking configuration too aggressive — Some firmware crashes at startup when given voltage/frequency parameters the hardware cannot handle.

Fix steps:

# Check if the mining daemon is running
ps | grep -E "cgminer|bmminer|bosminer"

# Attempt to restart it manually
/etc/init.d/cgminer restart
# or on newer firmware:
systemctl restart bmminer

# Check the crash log for details
cat /var/log/messages | tail -100

# On S19/S21 with Bitmain firmware:
cat /tmp/log/bmminer.log | tail -200

# Reset miner configuration to defaults
# WARNING: This erases pool settings
/etc/init.d/cgminer stop
cp /etc/config/cgminer.default /etc/config/cgminer.conf
/etc/init.d/cgminer start

1. SSH into the miner and check if the process is running. If not, try restarting it manually.
2. Read the crash log to identify the specific cause (hardware init failure, config parse error, etc.).
3. If the config file is corrupted, reset to defaults and re-enter your pool settings.
4. If the daemon crashes immediately after restart, the problem is likely hardware. Check the kernel log for hashboard errors.
5. If nothing works, reflash firmware via SD card.

Firmware Update Failed

What it means: A firmware update initiated via the web interface or SSH did not complete successfully. The miner may be stuck on old firmware, bricked (won’t boot), or in a partial-flash state.

Possible causes:

1. Power loss during flash — The absolute worst scenario. A power cut during firmware write can corrupt the NAND flash.
2. Wrong firmware file — Uploading firmware for a different model (e.g., S19 Pro firmware on an S19j Pro).
3. Network interruption — Upload was incomplete.
4. Insufficient flash storage — Log files or temporary files consuming available NAND space.

Fix steps:

1. Do not panic. Most “bricked” miners can be recovered via SD card boot.
2. Download the correct firmware file for your exact model and hardware revision from the manufacturer’s website.
3. If the web interface is still accessible, try the update again. Ensure you are using a wired connection (no WiFi) and no one will trip over the power cable.
4. If the miner is bricked (no web interface, no SSH), use the SD card recovery method (next section).

SD Card Boot Issues

What it means: SD card boot is the emergency recovery method for Antminers. You write a recovery image to a microSD card, insert it into the control board’s SD slot, and boot from it to reflash the firmware. When this process fails, you are dealing with a hardware-level problem.

Procedure for SD card recovery:

1. Download the recovery image for your exact model from Bitmain’s support page or D-Central’s firmware library.
2. Use a tool like Win32DiskImager (Windows), balenaEtcher (cross-platform), or dd (Linux/macOS) to write the image to a 4GB–16GB microSD card (larger cards may not be recognized).
3. Power off the miner. Insert the microSD card into the SD slot on the control board.
4. Power on. The miner will boot from the SD card and automatically reflash the NAND.
5. Wait for the process to complete (typically 5–10 minutes). The miner will reboot.
6. Remove the SD card and power cycle one more time.

Common SD card boot failures:

• Wrong image format: The SD card must be raw-imaged, not just have the firmware file copied onto a FAT32 partition (for most models). Some newer models do use a file-on-FAT32 method — check your model’s documentation.
• SD card too large: Cards above 16GB sometimes are not recognized by older control boards.
• Corrupted SD card: Try a different card. Cheap cards from unreliable sources often have bad sectors.
• Control board SD slot failure: If multiple known-good cards fail, the SD card reader on the control board may be damaged.

Diagnostic Commands

When in doubt, SSH into the miner and gather data. These commands give you raw diagnostic information that tells you exactly what the miner is doing — and what is going wrong. Default SSH credentials for most Antminers are root / root (or admin on some newer firmware).

# ===== Connect to your miner =====
ssh root@MINER_IP
# Default password: root (change this for security!)

# ===== 1. Check miner status overview =====
# API status query (works on most Antminer firmware)
echo '{"command":"stats"}' | nc localhost 4028 | python -m json.tool
# For a summary view:
echo '{"command":"summary"}' | nc localhost 4028 | python -m json.tool

# ===== 2. Check hashboard detection and chip count =====
echo '{"command":"stats"}' | nc localhost 4028 | grep -E "chain_acn|chain_acs|freq"
# chain_acn = actual chip number (should match expected)
# chain_acs = chip status string (o = online, x = dead)

# ===== 3. View temperature readings =====
echo '{"command":"stats"}' | nc localhost 4028 | grep -i "temp"
# Look for chip temp and PCB temp per chain
# Healthy chip temp: 50-80°C depending on model

# ===== 4. Check fan speeds =====
echo '{"command":"stats"}' | nc localhost 4028 | grep -i "fan"
# Expected: 3000-6000 RPM depending on model and load
# 0 RPM = dead fan

# ===== 5. View kernel log for errors =====
dmesg | grep -iE "error|fault|fail|warn"

# ===== 6. Check mining daemon log =====
cat /var/log/messages | grep -iE "bmminer|cgminer" | tail -50
# On S19/S21:
cat /tmp/log/bmminer.log | tail -100

# ===== 7. Network diagnostics =====
# Check IP configuration
ifconfig eth0
# Test internet connectivity
ping -c 4 8.8.8.8
# Test DNS resolution
nslookup stratum.slushpool.com
# Check pool connection status
echo '{"command":"pools"}' | nc localhost 4028 | python -m json.tool

# ===== 8. Check system resources =====
# Memory usage (low memory can crash the mining daemon)
free
# Disk usage (full NAND causes issues)
df -h
# System uptime
uptime

When to Seek Professional Repair

Home diagnostics and basic troubleshooting can solve many Antminer issues — loose cables, dirty fans, network misconfigurations, firmware reflashes. But some problems require professional repair equipment, specialized parts, and experienced hands. Here is how to know when to stop troubleshooting and send it to a pro.

Send it for professional repair when:

• Multiple ASIC chips are disabled or failing — BGA rework requires a preheating station, hot air rework station, fresh BGA chips, flux, stencils, and experience. One wrong move and you cook the entire board.
• Hashboard voltage domains read 0V or far off target — Failed voltage regulators (MOSFETs, buck converters) need SMD soldering skills and replacement components.
• Burnt or damaged PCB — Visible burn marks, cracked traces, or bulging capacitors indicate component-level failure that requires diagnosis and precision repair.
• Control board not booting after SD card recovery — If the NAND is permanently corrupted or the processor is dead, the control board needs replacement or reflash with a JTAG programmer.
• EEPROM data corrupted on a hashboard — Reprogramming the EEPROM requires reading data from a donor board and a chip programmer.
• Intermittent hashboard detection that persists after cable replacement — Could be a cracked solder joint on the connector pad, a damaged PCB trace, or a failing SPI buffer chip.
• PSU output is noisy or sagging — PSU repair involves high-voltage AC work (dangerous) and electrolytic capacitor replacement. Always replace rather than repair PSUs unless you are a trained power electronics tech.

What to expect when you send a miner for repair:

1. Request a quote — Contact D-Central with your miner model, symptoms, and the diagnostic data you gathered from this guide.
2. Ship the miner — Send the unit (hashboards only, or full miner) to D-Central’s facility at 1325 Rue Bergar, Laval, QC H7L 4Z7.
3. Diagnostic report — D-Central’s technicians run a full board-level diagnostic and provide a detailed report with findings and repair cost estimate.
4. Approve and repair — Once you approve the quote, repair work begins. Typical turnaround is 1–3 weeks depending on parts availability.
5. Testing and return — Repaired boards are burn-tested for 24–48 hours before shipping back to verify stable operation.

Quick Reference: Error-to-Action Table

Use this table when you need to move fast. Find your error, take the action, and reference the detailed section if the quick fix does not resolve it.

Frequently Asked Questions