IceRiver Reset Button Red Status Light Blinking: What It Means
ICERIVER_RED_BLINK — reset button was held, red status LED flashed to confirm registration, but the unit did not return to a normal-running state and remains parked at a red-blink pattern. Causes cluster into five buckets: (1) incomplete factory reset with interrupted partition copy (operator power-cycled mid-`mmc write`); (2) firmware corruption pre-existing the reset attempt (third-party firmware overwrote the factory partition); (3) hardware fault asserted during boot probe (hashboard chip count, fan-tach, temp sensor I2C, PSU handshake); (4) reset GPIO miswired or button mechanically stuck; (5) eMMC end-of-life on older units. Decode by blink pattern: 1-blink steady ~1 Hz = recovery in progress (wait `5-10 minutes`); 2-blink burst = firmware partition fault; 3-blink burst = SD-card recovery expected; 4-blink burst = hardware probe failed; 5-blink burst = critical hardware fault. Affects all KS-series units (`KS0` through `KS5M`) but KS5L/KS5M have additional hold-during-power-on edge cases on certain hardware revisions.
Warning — Should be addressed soon
Symptoms
- Reset button was held (`20 seconds` documented), released, and instead of returning to normal operation the red status LED started blinking
- Web UI is unreachable at the unit's last-known IP — DHCP lease may or may not have refreshed
- Front-panel LED (`D1`-`D4` block on KS5L/KS5M, single status LED on KS0/KS3 family) is showing a red blink at a regular cadence
- Chassis fans running, stopped, or cycling — cycling is the most diagnostic of the three states
- Power LED on PSU still solid green — PSU is fine; problem is downstream on the control board
- Network cable yellow/green link lights are off — Ethernet PHY hasn't come up because the kernel hasn't booted
- Pool dashboard shows the unit as offline; last share was around the time you pressed reset
- Repeated reset attempts seem to do *less* each time — a partially-written partition is getting deeper into corruption
- On KS5L/KS5M with `D1`-`D4` block: pattern doesn't match runtime fault patterns (`D1+D3` fan, `D1+D2` network, `D2+D3` overheat, `D4` solid PSU)
- Reset was attempted shortly after a firmware update (OTA or SD-card) — strong indicator of firmware-state mismatch
- Reset was attempted on a unit running undocumented third-party firmware (`xyys`, `tswift`, `rdugan/iceriver-oc`)
- Blink cadence is rapid stuttering (`>4 Hz`) — points at eMMC failure or stuck reset GPIO
- Blink cadence is grouped bursts (e.g., 3 blinks → pause `2 s` → repeat) — bootloader reporting a specific fault state, not normal reset
Step-by-Step Fix
STOP. Set a timer for `10 minutes` and walk away. A unit mid-reset is busy — the bootloader is performing a `mmc write` operation that takes between `3 minutes` (KS0) and `8 minutes` (KS5L/KS5M with larger eMMC). Photo the blink cadence before walking away so you have data when you come back. If LED returns to normal pattern (green steady or single LED flash with steady fans) within `10 minutes`, you're done — go to step 9.
Document the LED pattern. Phone camera, video the blink for `15 seconds`. Count blinks per second. If grouped in bursts, count blinks per burst and pause length. Match against the blink decoder table on this page. The pattern tells you whether you're in normal-recovery, firmware-corruption, hardware-fault, or eMMC-failure territory — and that determines every step that follows.
Cold power-cycle from the breaker, `60-second` floor between off and on. PSU rocker switch alone is not enough — residual capacitance on the control-board `5 V`/`3.3 V` rails can hold reset state. Switch OFF at the wall breaker, wait full `60 seconds` (drains rails, clears SoC reset logic, evaporates RAM), switch back on. Watch LED for next `10 minutes` without touching anything.
Verify nothing else changed in your environment. Flashed third-party firmware recently? Ran an OTA update? Moved the unit to a new circuit? Added a UPS? Each of those introduces variables that interact with reset behaviour. Note any recent changes — they steer the diagnosis.
Check the reset button isn't physically stuck. With the unit off, look at the button. Is it sitting flush, or has it sunk into the chassis? Press it gently — does it click and rebound? If it sticks, lubricate with a drop of isopropyl, exercise it five times. A stuck button keeps reset asserted, which is why your unit appears to be in perpetual reset.
Multimeter the reset button electrically. Power off at breaker. Open chassis (model-specific rear-panel screws). Locate reset button leads on the control board. Continuity test with button NOT pressed: must read open (`>1 MΩ` or `OL`). Closed reading = mechanically stuck button or shorted trace; the unit is being told to reset on every poll cycle. Replace button (Tier 3) or exercise + clean (Tier 1).
Verify PSU is healthy under load. Multimeter on DC, probe at the PSU-to-control-board connector during boot attempt. Expect `12 V` rail (varies per model — check chassis sticker). Sagging below `11.4 V` during boot = PSU on its way out, control board is browning out mid-init, you'll get a stuck-blink pattern that has nothing to do with reset. Swap PSU with a known-good unit before continuing.
Try a longer reset hold. Some KS5L/KS5M hardware revisions have a longer reset-detect debounce than documented. Power on, wait the full `2 minutes` for boot attempt to settle, then hold reset for `30 seconds` (not the documented `20 seconds`). Watch for the red LED flash that confirms the daemon registered the hold. Release. Wait the full `10 minutes`.
Try the KS5/KS5L/KS5M hold-during-power-on procedure. Some hardware revisions disable the runtime reset GPIO during normal operation as a safety measure. Power off at breaker. Wait `30 seconds`. Press and hold reset. While still holding, switch the breaker back on. Continue holding `30 seconds` after power-on. Release. Wait `10 minutes`.
Verify network path after a successful reset. Check router DHCP lease table for the unit's MAC; you should see a fresh lease at a default hostname (typically `ICERIVER-<suffix>` or `KS3M-<suffix>`). Sticky reservations on the old static-IP can prevent fresh lease assignment. Remove old reservation, retry. Default web UI password is documented in `iceriver.io/faq/` per model.
SD-card recovery reflash. Download current stable IceRiver firmware for your KS model from `iceriver.io/firmware-download/`. Image to fresh SD card (`16 GB` Class 10 minimum) with `balenaEtcher` or `Rufus`. Power off. Insert SD card into control-board slot. Power on with reset held `30 seconds`. Recovery flash runs `15-20 minutes`. LED cycles through several states. Do NOT interrupt — interrupted recovery flashes brick the unit deeper than the original problem.
UART diagnosis (advanced). USB-to-TTL adapter (`CH340`/`CP2102`/`FTDI`, `3.3 V` logic) connected to model-specific debug header on the control board. Serial terminal (`PuTTY`, `minicom`) at `115200 8N1`. Power-cycle and capture U-Boot output. The U-Boot log tells you exactly which probe is failing — hashboard chip count, fan tach, temp sensor I2C, eMMC read/write. Single most-valuable diagnostic step on a deeply stuck unit.
eMMC health check via UART. From U-Boot prompt: `mmc info` reports the eMMC health if the controller exposes it. Look for high erase-cycle counts (over `90%` of rated cycles is end-of-life). High counts on a `2-3 year` old unit point at eMMC failure as the root cause of reset misbehaviour — you can flash firmware all day and the writes won't stick.
Reset button replacement. If multimeter (step 6) shows the button is mechanically failed: desolder existing button (`SMD tact switch`, model-specific package — `6mm × 6mm × 5mm` is common). Replace with equivalent. Reflow with `60/40 leaded` or `SAC305` lead-free. Power on, retest reset behaviour from Tier 1 step 1.
Roll firmware to a known-good prior version. If reset misbehaviour started immediately after a specific firmware update, the firmware is suspect. Download prior stable from `iceriver.io/firmware-download/` (or D-Central's archive if older versions are no longer hosted). SD-card reflash to that version. Some firmware versions ship reset-flow regressions patched in subsequent releases.
Stop DIY and ship to D-Central when (a) SD-card reflash failed or won't run, (b) UART showed eMMC end-of-life or a hardware probe failing you don't have parts to fix, (c) reset button is electrically failed and you don't have desolder/reflow capability, or (d) unit is on undocumented third-party firmware and one DIY attempt has already deepened the corruption. Tier 4 destination has UART harnesses, eMMC programmers (`Z3X`/`RT809H`), stock firmware images for every KS model + hardware revision.
D-Central bench process: UART capture on known-good harness for your specific KS model + hardware revision. eMMC programmer for direct chip-level read/write of boot, factory, and active partitions. Stock IceRiver firmware images for every KS model + hardware revision currently in the field. Reset button replacement if mechanical. Control-board swap if eMMC is dead and reflash through the programmer can't recover. `24-hour` burn-in at nameplate hashrate before return.
Ship safely. Pack the chassis in original or equivalent foam-lined box. Anti-static bags around any loose hashboards if removed. Include a note with: observed blink pattern (cadence + burst count), firmware running before reset, DIY steps tried, and recent environmental changes (new circuit, UPS, third-party firmware flash). Saves `30-60 minutes` diagnostic time per unit, which means a faster, cheaper repair for you.
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.