I’m having a persistent hardware issue with my PiKVM V4 Mini.
The device experiences brief but frequent interruptions, roughly once a minute or more often. During each event, the HDMI video feed blanks and returns on its own (typically 1 to 10 seconds later). During the same window, keyboard input to the target host stops being delivered, and even a brand new SSH connection to the PiKVM itself will hang until the event clears. Existing SSH sessions remain open but are unresponsive during the event.
Here’s what I tried:
Confirmed clean power delivery: vcgencmd get_throttled returns 0x0, vcgencmd measure_temp reads a normal 50.6°C, vcgencmd measure_volts reads a normal 0.87V core voltage.
Tested with two different power supplies (original power pack and a Dell 65W adapter), no change in symptoms.
Checked SD card health: no I/O errors in dmesg, no filesystem corruption in journalctl, card mounts cleanly.
Disabled onboard WiFi (dtoverlay=disable-wifi), no change.
Disabled CPU C-states in host BIOS, no change (this was a host-side test, since the freeze also affects host input delivery).
Checked /proc/interrupts before and after an event: no IRQ storm on any peripheral.
Watched dmesg -w and journalctl -u kvmd -f live through multiple events: no output logged during or immediately after a freeze.
Reviewed the firmware log via vclog --msg: no errors correlating to freeze timestamps beyond routine firmware messages.
Disconnected the ATX/RJ-45 cable to rule out electrical interference from that connection, no change.
Fully reflashed the SD card with a clean, current stock image from files.pikvm.org (v4mini-hdmi-rpi4-aarch64-latest.img.xz, linux-firmware-pikvm 20251021-2), with no custom configuration applied. The issue is still present on the fresh install.
The problem persists identically across two independent OS installs, with power, thermal, SD card, WiFi, and known software/firmware issues all ruled out, and with nothing logged at the OS or firmware level during the freeze. Could this be a hardware fault on the unit rather than a configuration or software problem?
Hi @russf ,
The PiKVM v4 mini’s 5v port isn’t power delivery aware, so it uses a fallback in actual PD power supplies that go back to a baseline 5v. This is why the Raspberry Pi 5.1V power supply is suggested as it provides slightly more power than a typically adapter and accounts for voltage drops to hold a better level for the PiKVM.
It does sound like something isn’t working properly if the network and SSH is not responding during these hiccups. Was this a kickstarter unit or purchased a couple years ago or fairly new?
The early units contained a CM4 unit that the Raspberry Pi Foundation has admitted had some PMIC issues (power management), which can fail and cause this kind of weirdness.
Reach out to support@pishop.us with your order information and they can help further diagnose and assess options for a potential replacement.
I’ve tried a Dell laptop 65W power supply - should be sufficient, yet the problem persists.
Being told that tech support requires me to post to either Discord or this forum, and to have a reply take almost two weeks to come back, these both justify my having since moved to a different solution.
I’ll repurpose the box as a general Raspberry Pi platform.
Eleven days on your first post and another six on your follow-up. That isn’t the turnaround you should have had, and I’m sorry. Before anything else, here’s the part that actually matters for you.
The Raspberry Pi Foundation has acknowledged a PMIC fault in a range of early CM4 modules, which is the module inside the V4 Mini. That’s a documented defect in the component itself, not wear and not a configuration problem. A unit of your vintage would normally sit outside the hardware warranty, but this fault is the exception: it’s handled on the basis of the acknowledged defect rather than on the unit’s age. So it is worth raising even though yours is a few years old.
As for why I think that’s what you’ve got, your results stand and mine didn’t. I pointed at
power delivery; you tested a second supply and the symptom persisted, and get_throttled at 0x0 means the rail never sagged. Existing SSH sessions surviving an event while new connections hang says the board isn’t browning out or resetting; it stops executing, then resumes. Video, HID and network stalling together with nothing logged at OS or firmware level is the signature of the whole SoC pausing, not a subsystem failing. The power theory is dead and you were right to push back on it. A PMIC fault also explains why every software-side test you ran came back clean: there was nothing running to catch it.
All I’d need is where you bought it (or backed it via Crowdfunding) and the serial from the sticker on the bottom. In an email to support@pishop.us and they’ll get it sorted.
For anyone else landing here, the normal route is:
Start with the reseller you bought from. The authorised list is at Buy - PiKVM
Bought through Amazon? A support request there is the fastest route.
Outside the Amazon return window, or if PiShop was the reseller or you aren’t getting a response from them: email support@pishop.us and we can work through things.
One last thing, on where to get help generally, because I don’t think we ever explained it.
The forum and Discord aren’t a queue you get put in instead of support. They’re where the software actually gets worked on. PiKVM’s developer is active in Discord, and that’s where real-time troubleshooting happens. The forum is the slower, more durable half: it’s indexed and searchable, so a writeup like yours is what the next person finds when they hit the same symptoms. Hardware faults still go through the reseller or PiShop, but for software and DIY questions those channels aren’t a runaround, they’re the direct line. If it read as being sent away, that’s our failure to explain it well enough.