IceRiver 0 Hashrate / 0 ASIC Chips Detected: Hashboard Diagnosis

Hard power-cycle at the breaker for 30 seconds, not a soft reboot. The IceRiver miner daemon can wedge after a firmware update or a brownout. A clean cold start clears the wedged state and lets the enumeration sweep run from a known boot path. About 10 % of `0 ASIC` reports we see fix at this step alone.

Verify chip count on the dashboard after the cold boot, not just hashrate. The web UI updates the chip count field as soon as enumeration completes — typically within 2-3 minutes of boot. If chip count is `0` after a 5-minute window, you have a real fault, not a transient. Hashrate climbs after pool authentication; chip count is the early indicator.

Power off at the breaker. Open the chassis and visually inspect every cable: ribbons and `12 V` power leads. Look for a connector visibly partially out of seat, blackened or scorched contacts, green / white oxidation, bent pins, or shipping damage. A visibly unseated cable is almost certainly your fix.

Reseat every ribbon and every `12 V` power lead, even ones that look fine. Disconnect, examine the contacts, reconnect firmly until you feel and hear the click. Vibration walks pins and a contact with `< 100 %` mating area passes idle traffic but fails enumeration timing. ~ 35 % of `0 ASIC` reports fix here.

Reboot and wait 5 minutes. Watch the chip count populate board-by-board — this is normal, not a fault. If after 5 minutes any board still reads `0`, you have not fixed it at Tier 1. Move to Tier 2 — multimeter work.

Multimeter on DC. Probe the hashboard `12 V` input pads (positive on the input pad, ground on chassis) under enumeration load. Reboot. Watch the meter during the first 60 seconds. Expect ≥ `11.8 V` sustained. A sag below `11 V` or oscillation = power-side fault. A clean rail under load = move on to data-side diagnostics.

Probe PSU output `12 V` directly at the PSU output connector while the miner is attempting enumeration. Same target — ≥ `11.8 V` under load. If the PSU is sagging here, the PSU is failing. On `KS5L` / `KS5M`, the `BP-H-3640` family is a known low-headroom design and sags under any extra load — replacement is the fix, not repair.

Swap suspect hashboards between slots on multi-board models. Label slots `0` / `1` / `2` with masking tape. Move the failing board to a known-good slot. Reboot. Fault follows the board → bad board. Fault stays in the slot → bad slot / backplane / controller data lane → escalate to Tier 3 / 4.

Verify firmware version against the chassis revision label. Cross-reference your installed firmware against the IceRiver download page. If firmware doesn't match silicon revision, flash the correct image. Factory-reset first (20-second button hold, red LED flashing confirms) for a clean state. ~ 25 % of `all-boards-zero` reports fix here.

Replace the ribbon cable on the suspect board if reseating isn't holding. Aftermarket ribbons in the correct pitch and length are inexpensive (`$15-$45 CAD` for a set). Don't fabricate one — the timing margins on the enumeration bus are tight and a hand-built cable will not meet them reliably.

Inspect and re-clean the C19 power inlet and the AC cord. The `200 W`-per-pin C19 socket on `KS3` / `KS5` runs hot near rated load and develops intermittent contact resistance that drops AC supply enough to make the PSU sag during enumeration. If the C19 plug is discolored at the pins, replace the cord and consider replacing the chassis-side socket if user-accessible.

Scope the controller's `clk` and `data` lines at the controller-to-backplane (or controller-to-hashboard) interface during the enumeration window. You should see characteristic toggling bursts in the first 60 seconds after boot. Flat or silent lines = controller data driver failure. This is bench territory but a 2-channel scope (Rigol DS1054Z or similar) is enough.

Inspect the hashboard's input PMIC and input MLCCs under magnification. Cracked MLCCs (often hairline) on the `12 V` input bulk caps cause rail collapse during chip enumeration current ramp. Replace any cracked MLCCs and any visibly damaged PMIC. PMIC replacement requires hot-air rework and a microscope — small package, tight pad pitch.

Re-flow chip-side power-domain MLCCs and the PMIC's exposed pad if you suspect a marginal solder joint rather than component failure. Preheat to `150 °C`, top-side at `310-330 °C` for 30 seconds. Lower-risk than chip-level reflow, still bench work — not field work.

Replace the on-board PSU on `KS5L` / `KS5M` if you've confirmed the `12 V` output sags. The internal `BP-H-3640` family is the known weak link. Aftermarket replacements available through Zeus Mining and through D-Central (when in stock). Match connector and form factor exactly — this is not a universal-PSU swap.

Roll firmware to the last-known-good version for your specific revision. If a recent OTA broke enumeration, the rollback path is: factory-reset (20-second button hold), then SD-card reflash with the known-good image (IceRiver provides recovery instructions in their FAQ). Do not flash 'newer' firmware as a fix — match revision exactly.

Stop DIY and ship to D-Central when: controller data lines are silent and you've ruled out PSU and firmware (control-board failure, requires bench imaging); a hashboard PMIC is dead and you don't have hot-air rework + microscope + PMIC stocked; a backplane interconnect on `KS5L` / `KS5M` shows oxidation requiring resurfacing; or `0 ASIC` returns within 30 days of a Tier 3 repair.

Ship safely. Hashboards in anti-static bags. Whole chassis double-boxed with at least 5 cm foam every side — IceRiver chassis are not as rigid as Antminer chassis and ship-damage is a leading cause of intermittent `0 ASIC` reports. Include a note: model, hardware revision label, observed symptoms, firmware version, what you tried, and contact info. Saves bench time and your repair cost.

D-Central bench process: chassis-level inspection, AC-side and `12 V`-side measurements under instrumented load, ribbon and connector inventory check, hashboard-by-hashboard isolation in a known-good chassis, controller swap with cross-imaged eMMC if needed, post-repair 24-hour burn-in at nameplate hashrate. Turnaround `7-14` business days from receipt.

Note on chip-level repair scope: chip replacement on `KS5L` / `KS5M` requires the matching kHeavyHash chip and the IceRiver-flashed firmware blob. We currently diagnose, isolate, and quote a parts-bridge plan if your specific failure needs chip-level work. Worst case: salvage-grade hashboard from inventory, or referral to the matching repair partner — we'll be transparent about what we will and won't touch.