Innosilicon A10 Pro – Low Hashrate
Warning — Should be addressed soon
Symptoms
- Realized hashrate sustained below 90% of variant nameplate for 30+ minutes on stock Innosilicon firmware
- Web UI shows `Chain[X] find Y asic` where `Y` is less than expected per-chain chip count for the hardware revision
- One chain reports materially lower MH/s than the other two
- `kern.log` shows repeated `reg crc error` or `chip no response` lines on a specific chain
- Pool-reported hashrate 8-20% below what the miner UI claims (stratum-side reject leak or stale-share drift)
- Hashrate degraded suddenly after a firmware update, pool change, or algorithm switch
- Hashrate degraded gradually over weeks or months with no single event (aging / paste / caps / ambient)
- Per-chain inlet temperature trending 3-5 °C higher than recorded healthy baseline
- PSU fan audibly ramping during steady-state mining, not just at startup
- Chassis intake at the front mesh measures above 30 °C despite room ambient feeling normal
- AC line voltage at the PDU below 220 V sustained on 240 V split-phase (or below 202 V on 208 V commercial)
- Miner running on 110/120 V residential — cannot reach nameplate on standard NEMA 5-15 outlet
- Dashboard HW error / reject rate climbing above 2% on one or more chains
- Miner has been running 18+ months since last thermal paste refresh
Step-by-Step Fix
Hard power-cycle the miner for 5 minutes at the breaker. Not a soft reboot — full power-off long enough that hashboard capacitors discharge fully and the control board re-initializes cleanly. Record baseline hashrate on the status page before and after. Often enough on its own to resolve a wedged stratum connection or stuck firmware process after a pool change or network hiccup. Monitor 24 hours before closing the ticket; log the realized hashrate and kernel-log tail so you have a known-good baseline for future comparison.
Revert to the stock Innosilicon firmware image for your specific A10 Pro variant. Download from www.innosilicon.com/html/products/en/download1.html. Flash via the web UI firmware upload on revisions that support it, or via SD card on revisions that don't. Avoid third-party firmware entirely on Innosilicon hardware — DCENT_OS, Braiins OS+, LuxOS, and Vnish are all Bitmain-family projects and do NOT run on A10 Pros. Stock at a known-good version is the baseline, not a compromise.
Shop-vac the intake mesh, front grille, and fan blades. Use a soft-bristle brush for stubborn build-up. Do not use canned air near the hashboards — it drives dust into chip sockets and makes the problem worse. Schedule this as a recurring 30-day maintenance task. Community field data puts dust-alone hashrate loss at 5-10% per 30 days of neglect on front-to-back ASIC cooling paths, which is bigger than most firmware tweaks move the needle.
Verify intake air temperature at the front mesh with an IR thermometer aimed directly at the grille, not room ambient. Target ≤ 30 °C for sustained nameplate hashrate. Above 30 °C the firmware silently caps chip frequency to protect stability and you bleed hashrate with no named fault in the kernel log. A Canadian garage in July can hit 35 °C at the intake even with the door open — add a box fan, duct cooler air from the shady side of the building, or move the miner to a cooler space before summer bites.
Verify your pool, algorithm, and stratum endpoint before opening the chassis. Confirm you're mining the coin and algorithm you intend (ETC, QuarkChain, Octa, or whichever Ethash fork you chose post-Merge). Ping the pool's stratum host — latency above 200 ms round-trip silently burns share submissions on Ethash. Try a second pool with healthier infrastructure for 30 minutes. If realized hashrate on the pool rises to match the UI, you had a pool-side problem, not a miner problem. This resolves a surprising fraction of post-Merge A10 Pro tickets.
Measure AC input voltage at the PSU under full load. Multimeter on AC, probe at the PSU input with the miner hashing at steady state. Expect ≥ 220 V on a 240 V split-phase circuit, ≥ 202 V on 208 V commercial. An A10 Pro cannot reach nameplate on 110/120 V residential — if you're on a standard NEMA 5-15 outlet, that is the whole problem. Install a dedicated 240 V circuit via a licensed electrician before running anything else down this list; everything downstream assumes your feed is correct.
Measure DC rails at the PSU-to-hashboard connectors under load. Probe each of the three hashboard connectors in turn with the miner hashing at steady state. All three rails should match within a few mV of each other. One rail materially below the others = tired cable, damaged connector, or fault on that specific board. All three sagging together = tired PSU; swap with a known-good PSU of the same wattage class before suspecting the hashboards themselves.
Re-seat every flat ribbon cable and hashboard power connector in the chassis. Power off at the breaker. Disconnect each ZIF ribbon and each power connector in turn, inspect latch tabs for cracks, contact pins for corrosion or blackening, reconnect firmly, verify the ZIF latch snaps fully home — not partially. Innosilicon's G19-class ZIF latches are the single weakest connector on this chassis family; they walk loose under vibration and thermal cycling. Re-seating alone fixes a material share of 'mystery low hashrate' tickets.
Swap hashboards between the three slots to isolate the fault. Label slots 0 / 1 / 2 with tape. Power off at the breaker. Move the suspect board into a known-good slot, power up, observe the web UI for 15 minutes. If the fault follows the board = bad board (Tier 3 work). If the fault stays in the slot = bad control board / ribbon / cable path (Tier 4 or diagnostic Step 6). This single test eliminates half the possible fault domains in one move.
Check the control board's RTC coin cell. The A10 Pro G19-class control board carries a small CR2032 cell. A dead RTC drifts the system clock, which breaks pool authentications on some stratum servers and manifests as silent realized-hashrate loss. Multimeter across the cell: ≥ 2.8 V healthy, < 2.5 V dying. Replacement is a couple of dollars and thirty seconds of work, no tools beyond tweezers. Easiest fix on the entire list — worth ruling out before any invasive diagnostic.
Refresh thermal paste on all three hashboards. Arctic MX-6 or Thermal Grizzly Kryonaut. Remove heatsinks, clean old paste with 99% isopropyl alcohol and lint-free wipes, apply a uniform thin layer (don't glop it on), reassemble with correct heatsink screw torque — uneven torque cracks BGA solder on one corner and creates exactly the chip-drop pattern you're trying to fix. 18+ month old paste accounts for 2-5 °C of junction-temp headroom; expect 3-8% hashrate recovery on a thermally-drifted board. Schedule every 18-24 months as preventive maintenance.
Reflow the FIRST dropped chip in any short chain. Innosilicon's A10 ASICs are wired in serial comm chains per board — break at chip position N and every chip from N onward reports missing. The first missing chip is the one that actually failed; everything behind it is just orphaned. Remove heatsink, flux the BGA, preheat bottom side to ~150 °C, top-side hot air at 310-330 °C for ~30 seconds, cool naturally, re-apply paste, reassemble. Community data on BM-family reflow puts roughly 30% of 'dead' chips as actually cold solder joints resolved permanently by one reflow cycle.
Inspect voltage-domain capacitors on the suspect hashboard. Bulging electrolytics or cracked MLCCs near the power-domain ICs = replacement job. Identify the μF and voltage rating, order replacements rated for 105 °C minimum (not 85 °C — miners run hotter than consumer spec). Soldering-iron plus hot-air rework job, not a reflow job. Continuous 80 °C+ operation drifts stock electrolytics in 2-3 years; A10 Pros from 2020-2021 batches are now well past that window. If you're not confident with fine-pitch SMD rework, stop here and ship the board — a botched cap job damages adjacent components and raises the final bill.
Use the control board's `UART0` serial console to verify boot health. Three-pin header on the G19-class control board (GND / TX / RX). Connect a 3.3 V-logic USB-to-serial adapter at 115200 8N1. Open `screen`, `minicom`, or PuTTY on a host laptop. Power-cycle the miner and watch the full boot sequence. Distinguishes a network / UI software failure (boots cleanly to login prompt) from a boot-media problem (U-Boot hangs) from a dead SoC (no output at all). Most Innosilicon operators don't know this header exists — it's the single most under-used diagnostic on this hardware.
Roll firmware to the last known-good Innosilicon image for your specific hardware revision. Cross-reference your control-board silkscreen against the Innosilicon portal before flashing — the wrong image for a late-rev board can brick the control board, and Innosilicon does not publish a universal recovery image. Flash via the official mechanism for your revision (web UI or SD card, not both simultaneously). Do not attempt to flash any non-Innosilicon firmware; no credible open-source project supports A10 Pro hardware, and attempts otherwise usually end with a dead control board.
Stop DIY and book a D-Central repair slot when: per-chain diagnostics isolates the same chip position on two different boards (PCB-level cascade, not chip-level); a reflow on a suspect chip drifts again within 30 days (failing silicon, replace the chip don't reflow it twice); PMIC or voltage-domain IC damage is suspected; visible capacitor bulging, lifted pads, burn marks, or burnt-component odor are present; the control board's `UART0` console shows nothing on cold boot; or after a clean Tier 1-2 pass the miner still cannot sustain 90% of nameplate. You are now in test-fixture and Innosilicon-specific chip-replacement territory.
D-Central bench process for an A10 Pro low-hashrate repair: full diagnostic on a test fixture with programmable load; per-chain isolation including the domino-effect check (inspect voltage-domain neighbours of any replaced chip before they cascade into a second failure); chip replacement with Innosilicon A10 salvage or new-old-stock where available — note that Innosilicon ASIC salvage stock is thinner than Bitmain BM-family, and lead time on sourcing can add 5-15 business days to the turnaround; reflow, re-seal, then 24-hour nameplate burn-in on the original algorithm before return shipment.
Ship hashboards safely. Anti-static bags for each board, double-boxed with ≥ 5 cm of foam on every side. Include a printed note: observed symptoms, exact firmware version and build, AC voltage at your PDU under load, per-chain MH/s readings, the `Chain[X] find Y asic` output from the web UI, algorithm and pool, and your contact info. Every detail saves diagnostic bench time, which directly lowers your repair bill. D-Central ships Canada / US / international; repair turnaround is 5-10 business days plus any chip-sourcing lead 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.
