Antminer kernel log is the fastest way to diagnose why a miner stopped hashing, dropped hashrate, or keeps rebooting. Across S19/S21/L-series and many other models, the wording may vary, but the failure patterns repeat. 🔧
This guide focuses on the log lines users search for the most: find 0 asic, soc init failed, temp too high, fan lost, EEPROM, and CRC errors.
Where to find the kernel log (and why it matters)
The kernel log is the miner’s low-level startup and hardware health report: board detection, chip enumeration, temperature protection, fan checks, and critical hardware faults. It’s more useful than guessing, and it’s usually the first place a repair tech looks.
- Best practice: capture the log right after the failure happens.
- Don’t reboot 20 times: repeated restarts can hide the first useful error (and sometimes stress a failing board).
How to read a kernel log line in 30 seconds
- Timestamp: helps you locate the first failure event.
- Chain/board index: points to a specific hashboard position (Chain[0], Chain 1, hb0, etc.).
- ASIC count: shows whether chips are detected normally or missing.
- Protection triggers: overheat and fan faults can shut the miner down by design.
1-minute triage: what to check first
- Find the first ERROR (or the first line that mentions shutdown / power-off).
- Confirm board detection: are all chains present and stable?
- Look for cooling protection: fan + temperature lines matter more than people want to admit. ⚡
- Scan for EEPROM / CRC / init errors: these usually indicate board-level issues.
Kernel Log Cheat Sheet: the errors people Google the most
1) “Chain X find 0 asic” / “detected asic num less than design”
Meaning: the miner is not detecting chips on a hashboard at all (or detects fewer than expected).
- Common causes: hashboard failure, power instability to that board, damaged connectors/cables, or a short on the board.
- Fast checks: power down, reseat data + power cables, swap known-good cables, and see if the error follows the cable or stays with the board.
- Important: if the log repeatedly “powers off” a board during startup, stop forcing reboots and diagnose properly.
2) “ERROR_SOC_INIT: soc init failed!”
Meaning: initialization failed during startup. This can be control board related, but it’s often triggered by a hashboard fault (including shorts) that prevents normal init.
- Fast checks: test boot behavior step-by-step (one board at a time), verify PSU stability, and watch whether init fails only when a specific board is connected.
- Rule of thumb: if SOC init fails only with one board installed, that board is the prime suspect.
3) “Temp is too high” / “over max temp”
Meaning: thermal protection triggered and the miner throttled or stopped hashing to prevent damage.
- Fast checks: confirm fans reach proper RPM, clean dust, verify airflow direction, check ambient heat, and inspect heatsink contact.
- Real-world cause: poor heatsink seating or a bad thermal interface can overheat a local area even if room temperature looks fine.
4) “ERROR_FAN_LOST” / fan speed errors
Meaning: one or more fans are not detected or can’t reach required RPM, so the miner stops for safety.
- Fast checks: reseat connectors, swap fan positions, avoid low-RPM “quiet” fans that don’t meet miner requirements.
5) “EEPROM error” / “load EEPROM error”
Meaning: the miner can’t read required board data. This often points to a hashboard storage/config problem.
- Fast checks: ensure firmware flash completed cleanly and settings are sane. If only one board shows EEPROM errors, treat it as a board-level issue.
6) “CRC error” (nonce CRC / reg CRC)
Meaning: data integrity checks failed while communicating with chips. This commonly shows up as unstable hashing, random drops, or a board that “almost works” but won’t stay stable.
- Fast checks: compare behavior across boards, monitor whether the same chain throws CRC errors under load, and treat persistent CRC as a strong chip/signal-path indicator.
7) Pool / network errors (“socket connect failed”, DNS, etc.)
Meaning: connectivity problems (not always hardware). Some firmwares show these lines in the same log stream.
- Fast checks: verify pool URL/port, DNS, gateway, firewall rules, and test with a known-good pool preset.
Why stock firmware logs sometimes aren’t enough
Here’s the annoying part: stock firmware doesn’t always show the full story. Some builds hide detail, collapse repeating errors, or don’t display enough context around a failure. That’s why you can see “generic” messages even when the root cause is very specific (one chain, one sensor, one unstable voltage rail).
When it makes sense to use VNish (more readable logs)
If you’re troubleshooting an intermittent issue, VNish-based firmware can be a practical diagnostic tool because the logs tend to be more informative and easier to read, especially for chain-level behavior and stability issues. 💡
- Better visibility into what each chain is doing during startup and under load
- Cleaner, more structured error output (so you spend less time guessing)
- Helpful when a miner is “kind of working” but unstable (CRC, random drops, watchdog behavior)
Note: Installing third-party firmware may affect factory warranty and should be done carefully. If you want a supported option and a firmware source we stand behind, you can use our VNish partner firmware page:
Antminer Repair Firmware (VNish partner downloads)
When to stop experimenting and get professional diagnostics
- Repeated “power off hashboard” events on the same chain
- SOC init failures that persist after basic isolation steps
- One board repeatedly shows “find 0 asic”, EEPROM errors, or CRC errors even after cable swaps
- Overheat triggers quickly in a cool environment (often heatsink/thermal interface problems)
Need a fast answer? We can pinpoint the failing board quickly
If you’re stuck, send us the kernel log and a photo of the miner/boards. We do real board-level diagnostics, chip replacement, EEPROM recovery, and control board repair with full testing (not guesswork).
Contact our repair team today and get your miner back to full power. Contact us here.