Skip to content

We're upgrading our operations to serve you better. Orders ship as usual from Laval, QC. Questions? Contact us

Bitcoin accepted at checkout  |  Ships from Laval, QC, Canada  |  Expert support since 2016

CB_ERR Warning

Antminer – Green LED No Hashing

Green LED, No Hashing — the chassis status LED is solid green (Bitmain signal-light meaning: normal) but pool hashrate reads 0 TH/s sustained. Root causes cluster in stratum / network / TLS (dead CR2032 RTC battery drifts the clock and breaks pool cert validation), factory TEST-pool lockout after SD recovery, userspace mining-engine crash (`cgminer` / `bmminer` not running), hashboard chain-enumeration failure (`Chain[X] find 0 asic`), eMMC / SD firmware corruption, or custom-firmware brick. The green LED is a kernel-booted signal, not a hashing signal — Bitmain's firmware conflates them.

Warning — Should be addressed soon

Affected Models: Antminer S9, S9i, S9j, S9k, T17, S17, S17 Pro, S17+, S19, S19 Pro, S19j, S19j Pro, S19 XP, S19k Pro, S21, S21 Pro, L3+, L7, D3, Z9, Z11, KA3, K7 — effectively the entire Antminer line

Symptoms

  • Chassis status LED is solid green (Bitmain 'normal operation' signal) but pool hashrate reads 0 TH/s sustained for 30+ minutes
  • Fans spin at or near nominal RPM with no `ERROR_FAN_LOST` in the UI
  • Web UI loads at `http://{miner.ip}` and accepts credentials
  • Miner Status page shows blank / `--` hashrate, or UI-reported nameplate that the pool does not see
  • Pool dashboard shows the worker as Offline / Inactive / absent, despite web UI claiming to be hashing
  • `kern.log` or `/var/log/messages` is empty past the boot banner, or shows `Chain[X] find 0 asic` / `reg crc error` / `fail to read pic temp` / `ERROR_SOC_INIT` / `stratum_recv: auth failed`
  • SSH responds (or refuses) on port `22`; web UI reachable but the miner never joins the pool
  • RJ45 LEDs show normal link/activity — this is not a cable problem
  • Problem started after a firmware update, SD / eMMC recovery, PSU swap, network change, DHCP reservation change, pool migration, or power event
  • Miner left in factory `TEST` pool after an eMMC / SD recovery and never re-pointed to a real pool
  • Control-board `RTC battery` (`CR2032`) dead — clock drifts and stratum TLS cert validation fails silently
  • Recently flashed Braiins OS+ / LuxOS / Vnish / DCENT_OS — custom firmware that didn't complete cleanly or points at an unreachable pool
  • On stock Bitmain UI: `Pool: Dead` or `Pool: Alive: No` with no named reason in the status string

Step-by-Step Fix

1

Hard power-cycle at the PDU for 60 seconds — full power-off, long enough that control-board filter capacitors discharge. Not a web-UI 'Reboot' — that's a soft restart and does not clear wedged kernel state. Wait 10 minutes after power-on for DHCP lease, NTP sync, and stratum handshake to complete. Roughly a third of green-LED-no-hash reports resolve at this step alone. Record pool status before and after so you know what fixed it. If pool shows the worker Alive within 15 minutes, close the ticket and monitor for 24 hours.

2

Verify the pool configuration. Load the web UI → Miner Configuration → Pools. Read every field. Look for: the factory `TEST` pool address (common after SD or eMMC recovery — miner points at Bitmain's test endpoint that never accepts real work), a pool URL typo, wrong worker name or worker password, an obsolete pool URL that migrated. Fix the config, save, reboot, re-check pool status after 5 minutes. This is the single most-missed check in green-LED-no-hash tickets and it is always free.

3

Confirm network reachability from both sides. From your desk: `ping {miner.ip}` (expect replies), `curl -I http://{miner.ip}/` (expect 200). From the miner via SSH: `ping 1.1.1.1` (expect replies), `ping stratum.ckpool.org` (expect replies — if DNS is broken, only IP pings work). No reply = network issue. DNS-only failure = router or firewall stripping the query. Stratum-specific failure with ping OK = middlebox (AiProtection / corporate firewall / VPN split-tunnel) blocking stratum ports.

4

Disable any VPN, router AiProtection, or parental-control filter that might block stratum traffic. ASUS AiProtection, TP-Link HomeShield, and every enterprise firewall we've seen silently block mining-pool stratum endpoints. Whitelist the miner IP or disable the filter temporarily as a diagnostic. If the miner now hashes, you've found the blocker — add a permanent whitelist rule rather than leave the filter disabled fleet-wide.

5

Switch the pool URL to a known-good stratum endpoint as a diagnostic. Use `stratum+tcp://stratum.solo.ckpool.org:3333` with your Bitcoin address as the worker name (free diagnostic — and if you win a block, congratulations), or any major pool you already have credentials for. If the miner now hashes, your old pool config was the problem: wrong URL, expired credentials, migrated endpoint, or a pool that went offline. Log the old config for forensics before you overwrite it.

6

Check for factory firmware `TEST` pool lockout. Some Bitmain firmware builds ship with the pool field effectively locked to `TEST` — field edits are accepted by the UI but reverted at boot. Cross-reference Bitmain support article 21427190625945 against your firmware version and hardware revision. If affected, the path forward is a firmware update from Bitmain or a third-party firmware (DCENT_OS / Braiins OS+ / LuxOS / Vnish) that does not enforce the lockout.

7

SSH into the miner and check the mining process. Default S19-family creds are `root`/`root` or `root`/`admin` unless you changed them. Run `ps | grep -E 'cgminer|bmminer|mining'`. If the mining process is running but pool is Dead, issue is network / stratum / pool — re-run Tier 1 with the log in hand. If the mining process is not running, it crashed or never started — jump to step 12 (firmware re-flash) or read `/var/log/messages` for the specific error line.

8

Replace the `CR2032` RTC battery. Power off at the PDU, open chassis (Phillips #2 or Torx T10), locate the coin cell on the control board — typically near the RJ45 port or eMMC / SD slot. Measure existing voltage: healthy >2.8 V, dead <2.5 V. Replace with a fresh `CR2032` ($2 at any drug store). Close, power on, SSH in, set the clock: `date -s 'YYYY-MM-DD HH:MM:SS'` and configure NTP if available. Pool status should clear within minutes. This is the $2 fix Bitmain's `Pool: Dead` message hides, and it's the single most-missed diagnosis on aging Antminers.

9

Switch the miner to a static IP with a DHCP reservation. Long DHCP leases expire while the miner is powered off; the new lease may conflict with pool-side ACLs or router reservations. SSH in, set a static IP on the miner's LAN interface, or configure a DHCP reservation on your router keyed to the miner's MAC address. Reboot, confirm the miner has the expected IP and can ping the pool by name. This prevents the 'works on Monday, silent on Friday' failure class entirely.

10

Re-seat the hashboard data ribbon and power harness. Power off at the PDU. Label each cable with masking tape (slot 0 / 1 / 2) before disconnecting. Visually inspect pins for blackening, green oxidation, bent pins, or melted housing. Re-seat firmly until you hear the click. Power back up, SSH in, and `tail -f /var/log/messages` during boot — watch for the chain-enumeration lines. A clean re-seat often fixes intermittent enumeration failures that manifest as green-LED-no-hash.

11

Measure `+12 V` at the hashboard power input under load. Multimeter on DC, probe at the PSU-to-hashboard connectors with the miner in its current state (green-LED, boot, or post-boot). Healthy: `11.8 – 12.4 V` sustained on each rail. Rail at `<11.5 V` = tired PSU, damaged cable, damaged connector, or undersized circuit. Swap PSU with a known-good unit as the next step. Also measure AC at the PSU input — low line voltage (below 220 V on a 240 V circuit) drives the same sag pattern from the wall side.

12

Flash official Bitmain firmware via SD card (S9 / T9 / S17 / older S19) or eMMC + UART (S19 XP / S21 / newer). Download the exact firmware for your hardware revision from `service.bitmain.com/support/download` — check the control-board sticker, not just the model name. Wrong firmware for a late-rev board bricks the control board. SD-card procedure: write image with Etcher, insert card, hold RESET while powering on, release after 5-10 seconds, let the flash complete. eMMC path follows Bitmain article 10845468564633. Note: Bitmain firmware signing blocks downgrade via web UI — you must use a physical SD / UART flash to roll back.

13

Flash DCENT_OS — D-Central's own open-source Antminer firmware, the Mining Hackers' option. Preferred on S9 / S17 / S19 / S19 Pro / S19j / S19j Pro / S19 XP / S21 family. All the per-chip diagnostics, tuning, autotuning, Stratum V2 support, per-chain enumeration telemetry, and explicit stratum state-machine dashboard of the commercial alternatives — fully open-source, maintained publicly on GitHub, no licensing fees, no vendor lock-in. DCENT_OS surfaces the kernel → userspace → mining-engine → stratum boundary explicitly, which is the single most valuable diagnostic upgrade on a green-LED-no-hash miner. Install per the landing page at `d-central.tech/dcent-os/`.

14

Flash an alternative third-party firmware if DCENT_OS does not yet cover your specific model. Braiins OS+, LuxOS, or Vnish. Each exposes per-chip HW% and chain-enumeration state. Use the Braiins OS+ SD-card trick for a zero-risk test: run Braiins from SD, pop the card to revert to Bitmain firmware instantly. Install per vendor documentation. Watch the stratum state — if it stalls at `CONNECTING` or `AUTHORIZING`, issue is network / TLS / auth; if it stalls at `MINING` with zero shares, issue is hashboard enumeration.

15

Recover from a custom-firmware brick. If you flashed Braiins / LuxOS / Vnish / DCENT_OS and the miner now sits green-LED-no-hash, the mining stack either crashed or the firmware didn't match the hardware revision. Path back: SD-card recovery to stock on S9 / T9 / S17 / older S19; eMMC UART recovery on S19 XP / S21 / newer. Note: Bitmain firmware signing blocks downgrade from the web UI on modern firmware — the only path back is a physical SD / UART flash with the correct image for your hardware revision.

16

Chain-level chip diagnosis using DCENT_OS or Braiins OS+. If the log shows `Chain[X] find 0 asic` or `Chain[X] find Y asic` with `Y` short of expected, custom firmware gives you per-position visibility. Zeus Mining's teardown shows the S19-family serial comm chain breaks at chip position `N`, orphaning all positions downstream — identify the first failing position. Reflow the suspect chip: preheat 150 °C bottom side, top-side hot air 310-330 °C for 30 seconds, let it cool, re-apply paste, reassemble. Community data: roughly 30% of 'dead' chips are cold solder joints that a single reflow resolves permanently. If the chip drifts again within 30 days, the chip is failing silicon and must be replaced.

17

Stop DIY and book a D-Central ASIC Repair slot when: (a) both stock Bitmain re-flash and DCENT_OS / Braiins have been attempted and the miner still sits green-LED-no-hash, (b) hashboard enumeration fault follows the board across a slot-swap and re-seating ribbons didn't fix it, (c) eMMC UART recovery is needed and you don't have the fixture / cable / image bundle, (d) control board needs replacement (visible damage, PMIC fault, clock drift that persists after battery replacement), or (e) you see capacitor bulging or burnt-component smell. You're now in test-fixture territory — the DIY path has run out of upside. Turnaround 5-10 business days; Canada / US / international.

18

D-Central bench process for a green-LED-no-hash miner: test fixture with programmable load and official Bitmain test binaries; control-board SD / eMMC recovery including UART unlock on S19 XP / S21; RTC battery replacement and clock oscillator validation; per-chip isolation with the Zeus Mining domino-effect check (inspect voltage-domain neighbours of any replaced chip to catch cascade failures before they bite you again); chip replacement with graded BM1398 / BM1362 / BM1368 / BM1393 salvage or new-old-stock where available; reflow, re-seal, 24-hour nameplate burn-in before return. Ship hashboards in anti-static bags, double-boxed with ≥ 5 cm foam on every side. Include a note with observed symptoms, firmware version, log excerpts, and pool config — saves diagnostic time and your repair cost.

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.