The recurring hard power-off/reboots of telep-mainframe are root-caused and fixed: the RTX 3080 had a missing / unplugged 12V PCIe power connector — one of its three separate PSU cables was disconnected. Reconnected during reassembly, then validated with a graduated CPU+GPU stress test that fully PASSED with zero crashes. This resolves the load-triggered reset behaviour that 2026-08-05-power-root-cause-nvme-damage-ups-kb-handover and 2026-07-24-psu-load-resets had been chasing.

ROOT CAUSE = an unplugged GPU 12V PCIe connector, now reconnected

The RTX 3080 is fed by 3 separate PSU PCIe cables (NOT daisy-chained), and one bank was disconnected. Under sustained combined load the card’s power delivery was starved → the box hard-cut. Reconnected during reassembly; a graduated stress test then ran clean to 250 W CPU + 450 W GPU cap with zero crashes.

The stress-test power caps are NOT persistent — they reset on reboot

The test’s CPU PL1/PL2 and GPU power caps do not survive a reboot. On the next boot the box reverts to the motherboard’s aggressive/uncapped CPU default and the GPU’s 320 W stock cap. Making a sane persistent power profile is still an open TODO.

What was wrong

  • The RTX 3080’s 12V PCIe power is delivered by 3 separate PSU cables (not daisy-chained); one bank was unplugged.
  • Result: under sustained combined CPU+GPU load, GPU power delivery was insufficient and the machine hard-cut. This is the mechanism behind the “turns off by itself under load” pattern.
  • Fixed by reconnecting the connector during reassembly.

Validation — graduated CPU+GPU stress test: FULL PASS

Graduated combined load, ~3 min per stage:

stageCPU PL2GPU power cap
1160 W320 W
2200 W360 W
3241 W400 W
4250 W450 W

Result: FULL PASS, zero crashes. Uptime climbed straight through all stages; the kernel journal stayed clean — no thermal / throttle / undervolt / MCE / hardware-error entries.

  • Peak GPU draw ~411 W; peak combined ~536 W (well within the Corsair 1000 W PSU).
  • GPU thermals plateaued 86–87 °C with no throttle; CPU 76–82 °C.
  • PSU is a Corsair 1000 W — adequate; it was NOT the fault.

For Agents — testing gotchas that shaped the readings

  • CPU stayed ~125 W in every stage because PL1 = min(125, PL2) is enforced under sustained load — PL2 only applies during the brief boost window. To actually stress the CPU rail harder, raise PL1, not just PL2.
  • GPU FP32 matmul load is compute-bound below the 450 W cap — it never reached the cap, so 450 W was never the limiter in this test.

Relationship to the earlier power notes

This is the resolution of the long-running power saga:

  • 2026-07-24-psu-load-resets framed a “PSU can’t sustain peak combined load” reset (default 16-thread CPU embedding as the reliable trigger). The real cause was the starved GPU power bank, not the PSU capacity (1000 W Corsair is plenty; peak combined here was ~536 W).
  • 2026-08-05-power-root-cause-nvme-damage-ups-kb-handover §6c upgraded it to “heavy CPU load triggers the brownouts on marginal mains.” With the connector reconnected, the graduated load test that would have tripped the old box ran clean — the load-triggered cuts are explained by the GPU connector, not marginal mains.

A UPS is still worthwhile — for genuine mains events

Reconnecting the GPU connector fixes the load-triggered self-offs. A UPS + NUT (the 2026-08-05-power-root-cause-nvme-damage-ups-kb-handover decision) still addresses genuine mains loss and stops the NVMe unsafe-shutdown / media-error bleed; the two are complementary. Once power is stable, still run the deferred fsck + NVMe self-test given the accumulated media_errors.

Open TODO

Persist a sane power profile

The stress-test caps reset on reboot (CPU reverts to the mobo’s aggressive/uncapped default, GPU to 320 W stock). Author a persistent CPU PL1/PL2 + GPU power-limit profile (e.g. a systemd unit applying nvidia-smi -pl at boot and an intel-rapl / MSR cap) so the box doesn’t run uncapped after every reboot.