Antminer – LED Blinking Red/Green
Warning — Should be addressed soon
Symptoms
- Control-board status LED alternates between red and green in a repeating pattern (not solid, not off)
- Miner is still hashing but realized hashrate sits 5-15% below nameplate
- Web UI at http://{miner.ip} loads, accepts credentials, and reports firmware version in the footer
- Miner Status page shows a named warning string: `ERROR_FAN_LOST`, `ERROR_TEMP_TOO_HIGH`, `Chain[X] find Y asic` (Y < nameplate), `ERROR_POWER_LOST`, or `fail to read pic temp`
- One or more fans audibly slower, silent, or reporting 0 RPM / `--` on the UI Fan tab
- `/var/log/messages` (S9) or `/var/log/bmminer.log` (S19-class) contains `fan_lost`, `temp_high`, `reg crc error`, or `Chain[X] find 0 asic` lines
- One hashboard reports fewer chips than the others on the Miner Status per-chain rollup
- Intake or exhaust noticeably warmer than baseline with no change in ambient or load
- Problem started after a firmware update, physical move, PSU swap, filter clean, power event, or seasonal ambient change
- Ethernet LEDs on the RJ45 look normal (green + yellow) — not a network issue
- Pool dashboard shows the worker as `Alive`/`Online` but pool-side effective hashrate is lower than the miner self-reports
- Blink ratio pattern: green-dominant with red flash every 3-5 seconds (fan/chip dropout), red-dominant alternation (thermal/enumeration), or even 1:1 (multi-fault)
Step-by-Step Fix
Open the web UI at http://{miner.ip} before touching hardware. Navigate to Miner Status and the Kernel Log tab; screenshot both. The LED is a pointer — the real fault code is almost always already named in the UI: `ERROR_FAN_LOST`, `ERROR_TEMP_TOO_HIGH`, `Chain[X] find Y asic`, `ERROR_POWER_LOST`, `fail to read pic temp`. If any of these are present you've skipped 80% of the diagnostic and can branch straight to the relevant subsystem step.
Count and time the blink pattern with a stopwatch before you reboot. Green-dominant with a red flash every 3-5 seconds = fan anomaly or single-chip dropout. Red-dominant alternation = hashboard enumeration failure or thermal climbing toward fatal threshold. Even 1:1 alternation = multi-fault state with two subsystems asserting at once. Log the ratio in your ticket or notebook — the pattern disappears after you clear the warning and the diagnostic clue goes with it.
Hard power-cycle at the PDU for 60 seconds — not a web-UI soft reboot. Full power-off lets the control-board filter caps discharge and forces a clean kernel re-enumeration of fans, hashboards, and PIC sensors. Roughly a quarter of mystery red/green alternations resolve after a clean cold boot if the cause was transient driver or sensor state. Watch the UI on reboot to see which subsystem comes back with a warning first.
Shop-vac the intake filter, wipe the intake grille with a dry microfiber, and blow out the chassis interior with compressed air at low PSI. Dust accumulation on the filter is the single most common cause of thermal warnings we see in the D-Central repair queue. Verify nothing is within 30 cm of the front intake or rear exhaust — no curtains, no walls, no stacked miners blocking airflow between units in a rack setup.
IR-thermometer the intake air right at the front grille. Target ≤ 35 °C for standard Antminer chassis, ≤ 40 °C water temp for Hydro models. Summer in an unvented Canadian garage easily hits 40 °C+ and triggers chronic red/green alternation; winter in the same garage drops to 0 °C and the miner loves it. Seasonal alternation warnings are almost always ambient — fix the room before you blame the hardware.
Power off at the PDU, open the chassis per the service procedure (Phillips #2, sometimes Torx T10 on S19-class), and physically inspect each fan. Spin each by hand — any grinding, resistance, or wobble = bearing failure. Check connectors fully seated on the control board. Look for black dust around the fan hub — classic dead-bearing signature. Replace any fan that doesn't spin freely. Never run the miner short a fan to test — thermal envelope is calibrated against the full array.
Re-seat every hashboard ribbon and power connector. Power off at the breaker, wait 60 seconds for caps to discharge. Disconnect each ribbon, inspect contacts for blackening or corrosion, reconnect firmly until you feel and hear the latch click. Do the same for PSU-to-board cables. Oxidation on these contacts is the most under-diagnosed cause of `reg crc error` and `fail to read pic temp` warnings that drive red/green alternation.
Multimeter on DC, probe at the PSU-to-board connector while the miner is fully hashing (not idle — it must be under load). Expect ≥ 13.8 V sustained on S19-class, ≥ 12.0 V on S9-class. Below target = PSU tired or circuit undersized. Swap PSU with a known-good unit of the same family. Do not mix APW families — APW3++ is not a drop-in for APW9. Consult Bitmain's PSU compatibility note before substituting.
Label the hashboard slots 0/1/2 (S9 / S19 / S21 = 3 slots, L7 = 4) with tape before moving anything. Swap the suspected-faulty board to a known-good slot and observe. If the low chip count or warning follows the board = bad board. If it stays in the slot = bad control path, cable, or control-board I²C. This is the cleanest way to separate board faults from control-path faults without test equipment.
Measure line voltage at the panel while the miner is under full load. On 240 V split-phase expect 235-245 V; on 208 V commercial expect 202-212 V. Low line voltage drives PSU sag, which drives intermittent `ERROR_POWER_LOST` warning-state flips that produce red/green alternation. If you're trying to run an S19-class miner on a 120 V circuit, stop — you are undersupplied by design and the miner will warn chronically.
Flash DCENT_OS — D-Central's own open-source Antminer firmware, the Mining Hackers' option. Per-chip HW% visibility, tuning, autotuning, stratum v2, and — relevant here — a dashboard field that names the subsystem behind every warning flag. No more guessing at blink ratios. Alternatives: Braiins OS+, LuxOS, Vnish. All four expose more diagnostic state than stock Bitmain firmware and turn the LED into a redundant visual.
Refresh thermal paste on any hashboard running PCB temps in the warning band (>75 °C S19-class, >65 °C Hydro). Remove the heatsink, clean residue with 99% IPA + lint-free wipes, apply a thin uniform layer of Arctic MX-6 or Thermal Grizzly Kryonaut to each chip. Pay attention to the PCH and voltage-domain ICs — dried thermal pads there are a common drift cause that elevates PCB temp without any individual chip being to blame.
Reflow a suspected dead chip on the low-count chain. If Step 9 isolated the fault to a specific board and Step 11 (DCENT_OS per-chip view) named position N as the break in the serial chain, reflow that position. Flux the BGA, preheat bottom-side to ~150 °C, top-side hot air at 310-330 °C for ~30 seconds, let cool naturally. BM1387/BM1397/BM1398/BM1362/BM1366/BM1368 packages all tolerate one reflow cycle well.
Replace a failed fan with a known-good spare. S9 fans are standard 120 mm 4-pin PWM, easy to source. S19-class fans are 120 mm 12 V with a custom connector — order from D-Central or Bitmain to match. Never run the miner short a fan to test; the thermal envelope is calibrated against the full fan array and you will trip fatal `ERROR_TEMP_TOO_HIGH` within minutes at nameplate load.
Roll firmware to the last-known-good version for your exact hardware revision. Verify the hardware table on Bitmain's downloads page (service.bitmain.com/support/download) before flashing — wrong firmware on a late-rev control board can brick eMMC. On S19 XP / S21 the recovery path is UART (USB-to-serial cable), not SD card — have it ready before you flash. Also check the known-regression community thread for stratum/warning-flag bugs on pre-2021-09-06 S19 builds.
Stop DIY when: per-chip reflow on the same position fails within 30 days; PMIC or voltage-domain IC damage is suspected (heat marks on MOS tubes near the PSU edge, measurable short, PIC temp reads that never stabilize); the fault follows the hashboard to every slot and re-seating + reflow hasn't helped; or any visible cap bulging or burnt-component odour. You are now in test-fixture territory. Book a D-Central ASIC Repair slot at https://d-central.tech/services/asic-repair/.
D-Central bench process: test fixture with programmable load; per-chip isolation using official Bitmain test binaries plus our own diagnostic loadout; chip replacement with graded BM1398/BM1362/BM1366/BM1368 stock; full reflow + reseal; 24-hour nameplate burn-in before shipping back. We also hot-swap dead PICs on control boards — a failure mode Bitmain support stops at `replace control board` for, which is 2-3× the price of a PIC swap.
Ship safely: anti-static bags on every hashboard and the control board; double-box with ≥5 cm foam on every face. Include a ticket note with: firmware version, observed blink pattern (green-dominant / red-dominant / 1:1), UI warning strings you screenshotted, and any kern.log excerpts. That note saves us diagnostic time, which saves you money on the repair invoice — typical savings 0.5-2 hours of bench time.
When to Seek Professional Repair
If the steps above do not resolve the issue, or if you are not comfortable performing these repairs yourself, professional service is recommended. Attempting advanced repairs without proper equipment can cause further damage.
Related Error Codes
Still Having Issues?
Our team of Bitcoin Mining Hackers has been repairing ASIC miners since 2016. We have seen it all and fixed it all. Get a professional diagnosis.
