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

VOLCMINER_RESTART Warning

Volcminer D1 Repeatedly Restarting or Reboot Loop Fix

VolcMiner D1 boots, hashes for some interval, hard-reboots without a clean shutdown. Cadence determines cause: sub-90s = PSU sag/electrical, 2-15 min = watchdog/firmware, > 30 min with day-night drift = thermal/ambient.

Warning — Should be addressed soon

Affected Models: VolcMiner D1, D1 Lite, D1 Mini, D1 Mini Pre, D1 Hydro

Symptoms

  • D1 boots, hashes for some interval, hard-reboots without a clean shutdown sequence
  • Boot-to-reboot interval roughly consistent (+/-20%) across multiple cycles, OR consistently irregular (random 30 s to 45 min)
  • No error banner in the web UI before the reboot — the dashboard is just gone, then comes back on next boot
  • `kern.log` / system log buffer (if captured before reboot) shows watchdog reset, oops, panic, or truncates mid-line
  • Hashrate never reaches 17 GH/s D1 nameplate (or 30.4 GH/s Hydro / 2.2 GH/s Mini Pre) before reboot fires
  • Fans audibly ramp during boot, settle into hash-load profile, then stop on reboot — repeat
  • PSU fan ramps during reboot itself (not just at boot) — sign of repeated inrush stress
  • Loop frequency increases over the day as ambient warms, decreases overnight when ambient cools — thermal pattern
  • Loop frequency spikes during evening hours (6-10 PM) — neighbourhood mains sag pattern
  • Loop started immediately after a firmware update — possible kernel regression or 'keep configuration' wipe
  • Loop started after a power event (brownout, breaker trip, lightning storm) — PSU or controller damage
  • D1 Hydro: loop started after coolant-loop top-up or pump-stop/restart event — water-temp sensor or pump-feedback fault

Step-by-Step Fix

1

Time the loop with a stopwatch. Record at least three boot-to-reboot intervals plus time-of-day for each. This is the single most diagnostic data point you can capture in 15 minutes and it determines which Tier you actually need. Sub-90 s = electrical (PSU/mains). 2-15 min = firmware/watchdog. >30 min with day-night drift = thermal/ambient. Random scattered = often cable/connector intermittent under vibration.

2

Move the D1 to a known-good dedicated 240 V circuit. The D1 pulls ~3,900 W, roughly 17 A continuous on 240 V. Sharing a circuit with anything heavy-cycling (HVAC, freezer, EV charger, neighbour's load) drops mains under load. Move the miner to a circuit where it is the only load, re-test for 30 minutes. If the loop clears, the fix is the circuit, not the miner.

3

Cold-start at the breaker for 60 s. Soft reboots from the web UI do not fully reset the controller's I2C bus or clear hung sensor state. A true cold start does. Watch the boot sequence: fans should ramp to 100% for the first ~10 s, then settle. Hashboards should report tmps within 60 s of boot. If a hashboard never reports, the loop probably is not a power issue — it is hashboard or controller.

4

Verify ambient temperature with an IR thermometer at the intake grille. D1 family operating range is 5-45 C ambient. Above 35 C, fan duty pegs and the thermal-protection path is one bad bearing away from firing. Move the miner, improve room ventilation, or duct cool air to the intake using D-Central cooling shrouds. Canadian summer installs in unconditioned space are the most common ambient-cause loop.

5

Verify firmware version and recent changes. Note the firmware build from the web UI. If you flashed in the last 7 days without ticking 'keep configuration', settings reset to defaults — including thermal and fan profiles, which may be stricter than what your hardware tolerates. Re-apply your custom profile (or revert to a known-good preset) and observe 2 h.

6

Multimeter on AC: measure line voltage at the outlet while the miner is hashing at full power (use a multimeter rated for 300 V AC, never assume off-load voltage represents under-load voltage). Expect 230-245 V on 240 V split-phase, 200-212 V on 208 V commercial. Below those = mains sag, return to Step 2 with a different circuit.

7

Open the chassis safely. Power off, breaker off, wait 60 s for capacitor discharge. Phillips #2 + Torx T15 / T20 on most D1 chassis (verify against your unit). Note screw locations on a labeled diagram before removing — D1 chassis screws vary in length and re-installing the wrong screw in the wrong hole damages brackets.

8

Inspect AC inlet, internal AC fuse, and PSU input harness. Look for blackening, melting, oxidation, bent pins. Internal AC fuse is commonly 15 A or 20 A, 250 V, fast-blow ceramic — verify against silkscreen. A blown fuse explains a hard fail; a degraded fuse holder under vibration explains a random-cadence loop. Reseat all connectors with a dab of dielectric grease.

9

Multimeter on DC: probe the 12 V logic rail at the controller-side connector while the miner is hashing (use insulated probes, do not slip). Expect 11.8-12.2 V sustained. Below 11.5 V = PSU sag at the rail level — either a tired PSU or a downstream short pulling the rail down. Move to Tier 3.

10

Multimeter on DC: probe the main hashboard rail (commonly ~14-15 V on Scrypt-class boards — verify against your D1 revision before assuming). A rail >0.5 V below nominal during steady-state hashing = PSU output stage tired or hashboard pulling more current than spec. Move to Step 11 for hashboard isolation.

11

Hashboard isolation. Disconnect each hashboard one at a time, boot. The controller will throw a chain-detection error but should run stable. If the loop clears with one board disconnected, that board is the fault — see volcminer-d1-hashboard-chain-error. If the loop persists with all boards disconnected, the controller or PSU is the fault.

12

Capture the kernel ring buffer over serial. Locate the controller's TTL UART header (commonly a 4-pin 0.1" header — verify pinout). USB-TTL adapter at 115200 8N1, ground common. Capture output through one full reboot cycle. Read the last ~50 lines: 'Reboot via watchdog' = watchdog reset (firmware/driver fault); 'Kernel panic - not syncing:' = real panic with backtrace; truncation mid-line = power-side reset.

13

Probe the PSU 5VSB / standby rail with an oscilloscope. Looking for ripple >100 mV pp, transient sags during load steps, or oscillation. A misbehaving standby rail crashes the SoC reset circuit cleanly without leaving a kernel trace, which is why power-side restart loops are often invisible in the log.

14

Inspect controller-board capacitors and inductors. Bulging or vented electrolytics near the SoC's brown-out detector, cracked MLCCs on the 12 V to 3.3 V step-down regulator, or a saturating inductor under load — any of these produce sub-90 s restart loops without an error message. Visual inspection plus ESR meter check on suspect electrolytics. Replace with same-package, same-spec parts.

15

Roll firmware to last-known-good build for your hardware revision. Pull from volcminer.com/techsupport, verify build matches your hardware (D1 vs Lite vs Mini Pre vs Hydro). Tick 'keep configuration' on the upgrade dialog. Observe 2 h post-flash. If the loop disappears on the older build, you have isolated a kernel regression — file a report with VolcMiner support and stay on the older build until they fix it.

16

PSU output-stage rework. A tired output-stage MOSFET, a degraded transformer secondary diode, or a dried-out output filter cap on the D1's internal PSU produces under-load sag that shows as a sub-90 s restart loop. Component-level replacement is well within Tier 3 if you have a hot-air station and a schematic mental-model of a typical SMPS — but if you don't, ship it.

17

Stop DIY and book D-Central ASIC Repair when: PSU output stage is suspect and you don't have a hot-air station; controller-side fault is suspect and you can't capture serial output cleanly; you've found visible board-level damage; or two firmware rollbacks in a row have not cleared the loop. The Mining Hackers have rebuilt VolcMiner-class chassis on the bench and we carry the parts inventory to do it without waiting on a vendor RMA.

18

D-Central bench process: programmable AC source for mains-sag simulation, oscilloscope characterization of every PSU output stage, controller-side rework (capacitors, MOSFETs, brown-out detector tuning), kernel-log capture via integrated UART rig, hashboard isolation against a known-good controller, full reflow of suspect joints, post-repair 24 h burn-in at nameplate. Pack the chassis (or just controller + PSU if you have isolated to that side) in anti-static bags, double-box with >=5 cm of foam, include a note with loop cadence, firmware version, and any kernel ring buffer you captured.

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.