IceRiver KS3M Indicator Lights Normal But No Hashrate (Pool Config)

Hard power-cycle the KS3M: pull the C13 power cord (not the side toggle), wait 30 seconds for the PSU caps to drain, plug back in. Wait 5 minutes for self-check, stratum subscribe, and first-share submission to complete. About 60% of stratum-hang flatlines clear here, especially when the event correlates with a router reboot or pool maintenance window. Lowest-effort first move and worth doing before any config changes.

Re-enter pool URL and worker syntax in the web UI Miner Configuration page. KS3M expects only the hostname in the Pool URL field (`stratum.kaspapool.example`) — strip any `stratum+tcp://` prefix and any `:port` suffix. Port goes in its own field (typical Kaspa pools: 5555, 2222, 8888). Worker name must be `WALLETADDRESS.WORKERNAME` with the dot separator. Password is `x` or empty. Save, click Restart, watch dashboard for 5 minutes. New-owner gotcha #1 on KS3M.

Compare local web UI hashrate vs pool-side hashrate. Open both side-by-side. Local 0 + pool 0 = stratum/config issue (Tier 1-2). Local 0 + pool nominal = web UI/API caching bug, reflash firmware (Tier 2). Local nominal + pool 0 = stratum desync, cold-cycle and monitor (Tier 1). Local nominal + pool ~67% of nameplate = one hashboard dead (Tier 3-4). Triage routes the rest of your fix path.

Test against a known-good alternative Kaspa pool. Configure Pool 2 to a different operator entirely (Herominers, F2Pool, Acc-Pool, ViaBTC, etc.), preferably in a different geographic region. Save, restart. If hashrate appears on the alternative pool, your primary pool was the problem (transient outage, IP migration, DDoS, blacklist). Stay on the alternative until your primary recovers, then revert. Keeps you mining while you debug.

Update DNS to public resolvers in the miner's network config. Web UI → Network → DNS settings → set to 1.1.1.1 and 8.8.8.8. ISP DNS sometimes silently fails on pool hostnames after a pool IP migration; a public DNS resolver fixes it instantly. Save, restart, watch dashboard 5 minutes. Free fix that resolves a non-trivial slice of green-LED-zero-hashrate cases.

Read the web UI logs and pattern-match. Web UI → System → Logs (or `http://<MINER_IP>/cgi-bin/log.cgi` on some firmware revs). Read the last 200 lines. `mining.subscribe` with no `mining.set_difficulty` = stratum subscribe is failing pool-side. Repeated `mining.submit` with no ack = socket half-open, firmware bug. `getaddrinfo failed` or `Name or service not known` = DNS dead. No stratum activity at all = ASIC controller or firmware-level hang. Each pattern routes to a different next step.

Reflash the latest stable firmware. Pull the .tar.gz from iceriver.io/firmware-download/, verify it matches your hardware revision sticker on the chassis bottom, web UI → System → Update Firmware → upload → confirm. The miner reboots twice. Wait 10 minutes after the second reboot for the dashboard to repopulate. Several KS3M firmware revisions in 2024-2025 shipped with a stratum-resubscribe regression and a cgi-cache bug that both manifest as exactly this symptom.

Roll back firmware if the latest is the problem. If the symptom started right after a firmware update and didn't exist before, download the prior version from IceRiver's archive (or use a `.tar.gz` you stashed locally before updating — best practice). Reflash the older version through the same web UI procedure, observe 24 hours. If symptom clears, the new firmware introduced a regression — file a ticket with IceRiver and stay on the older version until they ship a fix.

Factory reset (20-second hold + red light). Press and hold the rear reset button for 20 seconds until the front status LED turns red. Release. Unit reboots through full self-check (~3 minutes) and reverts to default IceRiver pool settings + DHCP. If hashrate returns on default config, your saved config was the issue — reconfigure from clean state, taking notes on what was different. If still flat on default config, escalate to Tier 3 hardware diagnostics.

Lock IP and DNS at the router level. In your router admin, reserve the KS3M's MAC address to a fixed IP via static DHCP. In the miner's network config, set DNS explicitly to 1.1.1.1 + 8.8.8.8, set gateway and subnet manually if your firmware allows. Eliminates DHCP-lease-expiry events and ISP-DNS-flap from the failure surface. Single most effective preventive change you can make.

Per-board temperature spread check + chip count. Web UI → Miner Status. Read all per-board temperatures. Spread should be within ±3 °C across the three boards. If one board reads <35 °C cold while others sit at 55-60 °C, that board has lost ASIC power or the chips are dead. Note which board (1, 2, or 3) for the next step. KS3M nominal chip count is 78 (3 boards × 26 chips); test-fixture readings of 9, 26, or 52 indicate partial chip failure per Zeus Mining's KS hashboard repair documentation.

Reseat the suspect hashboard's ribbon cable. Power off, pull the C13 cord, wait 60 seconds. Open the chassis lid (Phillips #2). Disconnect the suspect board's ribbon cable from the control board, inspect for blackened pins or oxidation, reconnect firmly until you hear the click. Same procedure for the power cable to the suspect board. Close, power up, observe for 15 minutes. Cable reseat clears roughly 20% of dead-board tickets per Zeus's KS hashboard repair documentation.

Swap the suspect hashboard to a different control-board ribbon connection if you have a spare bay or a second KS3M to test against. If the cold/dead symptom follows the board to the new slot, the board itself is dead. If the symptom stays in the slot regardless of which board is mounted, the control board or its ribbon cable is the problem. Standard ASIC isolation procedure adapted for KS3M's three-board chassis. Record the result before reassembling.

Inspect each hashboard visually for damage. With the chassis open, look at every board for: bulged caps near the LDOs, cracked MLCCs, scorch marks around the chip array, discolored solder pads, missing chips. Any of these means bench repair (Tier 4) — do not try to reflow blind. Photograph anything you find before shipping; saves D-Central diagnostic time and reduces your repair cost.

Voltage check at the LDO domain. Multimeter on DC. Probe the voltage rail to the chip array on the suspect board — per IceRiver's repair documentation, each domain feeds a row of chips through an LDO. Spec is typically 0.65-0.75 V under load. Below that = failed LDO. This is the threshold for shipping to D-Central; LDO replacement is bench work, not field work, and requires test-fixture verification afterward.

Stop DIY when: per-board temp shows a cold/dead board AND ribbon reseat didn't fix it AND voltage check shows a failed LDO domain. Same call when you see capacitor bulging, chip-array scorch marks, or the miner won't complete self-check after factory reset on default firmware. You are now in chip-replacement / domain-repair territory — bench instrumentation territory. Book a D-Central ASIC Repair slot.

D-Central bench process for IceRiver: KS hashboard tester fixture, LDO replacement, chip-level reflow on the kHeavyHash silicon, ribbon connector replacement, and a full burn-in at nameplate hashrate before return. D-Central is the Western English-language IceRiver hashboard repair authority — most shops in this space are Zeus (China, trust-deficient) or no one. Turnaround 5-10 business days, Canada / US / international shipping.

Ship safely to D-Central. Anti-static bag per board. Double-box with at least 5 cm of foam on every side. Include a note with: observed symptom (LEDs green, no hashrate), per-board temperature spread numbers from the dashboard, log excerpt if you captured one, firmware version, and your contact info. Saves us 30-60 minutes of bench diagnostic time and reduces your repair cost. Don't ship the PSU unless you suspect it — adds shipping weight without diagnostic value when the LEDs were green to begin with.