HW Power Brake (PWRBRK)

PWRBRK# is an optional PCIe sideband signal on edge pin B30 that lets a platform force a GPU into an emergency low-power state. Some motherboards and risers assert it all the time, and the CMP 170HX obeys it. A braked card unlocks, links and loads models normally, but sits at about 80-88 W and 1140 MHz and runs roughly 4x slower than a healthy one. nvidia-smi shows it as "HW Power Brake Slowdown: Active". The fix is tape over pin B30 or a riser that does not carry B30. Most boards never assert it, so check before you tape anything.

Symptoms

Stuck at about 80-88 W and 1140 MHz, roughly 4x slow

Two 8 GB cards on an Asus WRX80 Threadripper Pro workstation (Unraid 7.3.1, kernel 6.18.33, self-built NVIDIA open modules 610.43.03) unlocked fine: 65,536 MiB, Gen2 x4, MTP and pipeline parallel ran. But nvidia-smi showed "HW Power Brake Slowdown: Active" even at 34 W idle, power hit a hard cap of about 80-88 W under load, and SM clocks stayed at 1140 MHz (max 1695). The same benchmark script gave fp16 39 TFLOPS (6 before the unlock) against 152 TFLOPS on rented unlocked cards, and HBM about 650 against 1600 GB/s: roughly 4x down across fp16, bf16, tf32, fp32 and int8. It was identical on cmpunlocker v0.2 with and without P2P and on the v0.1 archive patch set, over three cold boots.

Ruled out: cables (2x 8-pin per card through the EPS adapter), risers (a card in a direct slot was identical), the PSU (an RTX 3090 on it was not braked), SM count (70), engine choice and temperature (35 C).
Suggestions that were not the cause: PCIe 2.0 x4 bandwidth starvation (withdrawn, since single cards braked too), BIOS options such as Above 4G decoding and Resizable BAR, a clean Unraid install and NVIDIA config, a clean driver wipe, and the wiring of the EPS adapter.
MTP with pipeline parallel does not force an 80 W cap by itself: another owner's cards pass 180 W running it on v0.2, and a third saw 187 W in ComfyUI.
dmesg showed "Booter failed with non-zero error code: 0x31" 36 times per card. Those lines are noise, not the cause; see Driver and unlock failures.

Peocua had the same fault on an X99 board and covered pin B30 on the card edge with high-temperature insulating tape. The WRX80 owner taped the pin on his risers and confirmed it: "they are flying now". Server-class GPUs obey PWRBRK#; RTX 3090s ignore it.

Proven 8 GB
Source: @sojun80, 2026-07-30
Source: @deejay9983, 2026-07-30
Source: @deejay9983, 2026-07-30
Source: @cute_sc2, 2026-07-30
Source: @_arcanum_, 2026-07-30
Source: @ju5t5omedude, 2026-07-30
Source: @deejay9983, 2026-07-30
Source: @shudza, 2026-07-30
Source: @_studebaker_, 2026-07-30
Source: @deejay9983, 2026-07-30
Source: @yuiayanami, 2026-07-31
Source: @sealclubber, 2026-07-31
Source: @artistosu, 2026-08-03

Braked against healthy: the recipe repos' readings

Warning The DeepSeek V4 Flash recipe repos (allover326, ElRoberto538 and Schaka) were produced on a board that asserts PWRBRK#, and their READMEs report one card braked and healthy:

	Braked	Healthy
Power draw	about 88 W of a 250 W budget	105-180 W
Clocks	1140 MHz	about 1400 MHz
fp16	39.3 TFLOPS	155.7 TFLOPS
Memory bandwidth	about 608 GB/s	about 1355 GB/s

These are the repos' readings. They say to rule the brake out first, because it looks exactly like "these mining cards are just slow" and cost them a great deal of time before they found it.

8 GB
Source: repo github.com/allover326/deepseek-v4-cmp170hx by allover326 on GitHub, posted by @deejay9983, 2026-08-05
Source: repo github.com/ElRoberto538/deepseek-v4-cmp170hx by ElRoberto538 on GitHub (posted in Discord by @robbbbbb7973)
Source: repo github.com/Schaka/deepseek-v4-cmp170hx by Schaka on GitHub (posted in Discord by @schakaqt)
Source: repo github.com/Schaka/170hx-journey by Schaka on GitHub, posted by @schakaqt, 2026-09-10

Check

nvidia-smi: "HW Power Brake Slowdown" reads Active

Run on the host with the cards:

nvidia-smi -q | grep -A1 "HW Power Brake Slowdown"

The flag reads Active only when the platform asserts the brake. "Active" on a card that is not thermally or power limited means the board or riser is asserting PWRBRK#. To count healthy cards in a 4-card box, nvidia-smi -q | grep -c "HW Power Brake Slowdown *: Not Active" should print 4. Then load the cards and check whether they reach about 250 W; a braked card never gets past about 80-88 W.

Reported 8 GB and 10 GB
Source: @darkmaniac7, 2026-09-12 (lab notes)
Source: repo github.com/Schaka/170hx-journey by Schaka on GitHub
Source: repo github.com/PixelML/club-170hx by PixelML on GitHub
Source: repo github.com/allover326/deepseek-v4-cmp170hx by allover326 on GitHub, posted by @deejay9983, 2026-08-05
Source: @deejay9983, 2026-08-11
Source: @cuddylac997, 2026-08-11

A live view, and what healthy cards read

xanthe_'s checks: nvidia-smi -a | grep "HW Power Brake Slowdown", and a live view with watch -n 1 nvidia-smi --query-gpu=gpu_name,pcie.link.gen.gpucurrent,clocks_event_reasons.hw_power_brake_slowdown --format=csv (add other fields as needed). His two cards read Not Active, with PCIe link gen 1 (max 2) and width x4 at idle, at 65/68 C and 60/69 C core/memory. Waka324 described the cause in short: some motherboards limit the card's power through a PCIe pin, and the "fix" is to tape that pin off. Look at the clocks and the power draw as well as the flag: on one quarter-clock card the flag read Active while its counter stayed at 0 us, and the brake was not confirmed as the cause (see Not the brake below).

Reported
Source: @cmdrwaka324, 2026-08-24
Source: @meromgreen, 2026-08-24
Source: @xanthefin, 2026-08-24
Source: @dingwei0049, 2026-08-24 (translated from Chinese)

llm-visuals shows it as a BRAKE badge

llm-visuals, a terminal dashboard, reads the NVML clock event reasons and shows the hardware power brake (bit 0x80, an external signal such as PWRBRK#) as a BRAKE badge, beside THERM, HW, PWR, SYNC and APP. More tools on Monitoring.

Reported 8 GB and 10 GB
Source: repo github.com/DingoOz/llm-visuals by DingoOz on GitHub, posted by @trustinter, 2026-10-16

Boards and risers known to assert it

The list is short and open. If your board or riser asserts PWRBRK#, post it on Discord with the nvidia-smi line so it can be added here.

ASUS Pro WS WRX80E-SAGE: asserted on its x16 slots

Warning The DeepSeek V4 Flash recipe repos document an ASUS Pro WS WRX80E-SAGE that asserts PWRBRK# on edge pin B30 of its x16 slots, which holds every card in "HW Power Brake" (the readings are in Symptoms above). A riser proved it: the same card in the same slot ran at full speed through a riser that does not carry B30. The first case in Discord was also an Asus WRX80 board; its owner says the board permanently grounds B30, a known board defect that ASUS will not cover under warranty (see Symptoms). Schaka's 170hx-journey, a PLX switch build, repeats the same check and fix. Board page: ASUS Pro WS WRX80E-SAGE SE WIFI.

8 GB
Source: repo github.com/allover326/deepseek-v4-cmp170hx by allover326 on GitHub, posted by @deejay9983, 2026-08-05
Source: repo github.com/ElRoberto538/deepseek-v4-cmp170hx by ElRoberto538 on GitHub (posted in Discord by @robbbbbb7973)
Source: repo github.com/Schaka/deepseek-v4-cmp170hx by Schaka on GitHub (posted in Discord by @schakaqt)
Source: repo github.com/Schaka/170hx-journey by Schaka on GitHub, posted by @schakaqt, 2026-09-10

An X99 board

Peocua had the same fault on an X99 board (model not given) and fixed it by covering pin B30 on the card edge with high-temperature insulating tape. His fix is the one that cleared the WRX80 case above.

Reported
Source: @yuiayanami, 2026-07-31

"Some ASUS boards", and risers

Merom Green identified the pin as pin 30, PWRBRK, on some ASUS boards, and linked an NVIDIA forum thread on Quadro RTX 8000 multi-GPU performance. 丁薇 called it a malicious motherboard design, most simply fixed by masking the pin or by editing the corresponding device list (translated from Chinese). The lab notes on Schaka's and PixelML's write-ups say some workstation boards and some risers assert it. No other board is named in the history so far.

Reported
Source: @meromgreen, 2026-08-24
Source: @dingwei0049, 2026-08-24 (translated from Chinese)
Source: @darkmaniac7, 2026-09-12 (lab notes)
Source: repo github.com/Schaka/170hx-journey by Schaka on GitHub
Source: repo github.com/PixelML/club-170hx by PixelML on GitHub

Fix

Tape only a card whose flag reads Active. If it reads Not Active, the slowness is something else (see Not the brake below), and taping gains nothing.

Cover pin B30, or use a riser that does not route it

Confirm the flag reads Active on the card (see Check).
Cover pin B30 on the card's edge connector with Kapton tape. B30 is on the B side, counted from the notch end. Tape on a riser's edge connector works too.
Or put the card on a riser that does not route B30; that needs no modification.
If the board's BIOS or BMC has an option for the signal, that works as well; many boards have none.
Rerun the check: the flag should read Not Active and the card should reach its power limit under load.

Do not test with an RTX 3090 in the same slot: 3090s ignore PWRBRK#, so a 3090 runs at full power on a board that brakes the 170HX.

Reported 8 GB and 10 GB
Source: @darkmaniac7, 2026-09-12 (lab notes)
Source: repo github.com/Schaka/170hx-journey by Schaka on GitHub
Source: repo github.com/PixelML/club-170hx by PixelML on GitHub
Source: repo github.com/allover326/deepseek-v4-cmp170hx by allover326 on GitHub, posted by @deejay9983, 2026-08-05
Source: @deejay9983, 2026-07-30
Source: @yuiayanami, 2026-07-31

DeeJay's tape method (2026-08-11)

DeeJay's cards could not exceed 20-30 t/s because his board held them to about 80 W from the PCIe bus. He put Scotch tape over the pin he called "BR30", 19 pins over from the key on the left side (B30 is PWRBRK# in the standard x16 pinout): he laid a strip and sliced between the pads with a razor blade, about 5 minutes per card, and posted a PCIe x16 pinout and photos. Earlier, Peocua used high-temperature insulating tape, and other write-ups use Kapton.

Reported 8 GB and 10 GB
Source: @deejay9983, 2026-08-11

Pointer: a longer write-up by @deejay9983 (his tape guide, which he said is in his repo; it was not linked) exists; see Discord. The guide waits for the author.

Pointer: longer write-ups of the symptom, the check and the Kapton fix are in Schaka's 170hx-journey (GitHub) and PixelML's club-170hx (GitHub). They are not reproduced here until the authors agree.

Not the brake

Slow, but the flag reads Not Active

cuddylac997's cards were slow, but the flag read "Not Active" and the cards later pulled 216-263 W under gpu-burn -tc, so his slowness was not the brake. A card that reaches about 250 W under load is not braked; look at Instability under load and Testing and burn-in instead.

Reported 8 GB and 10 GB
Source: @deejay9983, 2026-08-11
Source: @cuddylac997, 2026-08-11

Quarter-clock 8 GB card: flag Active, counter 0 us

eka2513's 8 GB card unlocked cleanly (64 GB, Gen2, 70 SMs), but every compute figure was exactly 1/4 of reference while memory performance was normal. Its brake flag read Active, but the brake counter stayed at 0 us, and the card ran at 1/4 at stock 8 GB as well, so the brake was not confirmed as the cause. The pin 30 suggestion came in reply; whether the pin was ever taped is not known. giaki3003 linked the card to rumoured "nerfed cards" that nobody has confirmed. Unresolved.

Reported 8 GB
Source: @eka2513, 2026-08-24
Source: @giaki3003, 2026-08-24

Pointer: a longer write-up by @eka2513 (the clock measurements and the causes ruled out) exists; see Discord. The details wait for the author.