OpenBSD Blog #11: Disabling Direct Rendering Manager on OpenBSD

Page created: 2026-02-09

Go back to my OpenBSD page for more entries.

Something was stealing my CPU when a monitor wasn’t plugged in

I set up an OpenBSD headless gateway/firewall installation by doing the usual stuff with a USB stick, monitor, and keyboard. This little x86 mini pc had been running Slackware Linux flawlessly for the last four years and I wasn’t expecting any trouble.

But when I SSH’d into it a day later (fully headless), I found that the terminal session would freeze for a whole second (I could keep typing, but I wouldn’t see what I typed until it "unfroze") and then be fine for five seconds, then freeze again.

I could even ping the machine and watch the response time for the packets to see the "freeze" or "lock up" happening:

64 bytes ... time=0.241 ms
64 bytes ... time=0.229 ms
64 bytes ... time=0.254 ms
64 bytes ... time=0.223 ms
64 bytes ... time=988.136 ms  <--- yikes!
64 bytes ... time=0.230 ms
64 bytes ... time=0.252 ms

I kept hooking up a monitor, trying a fix, thinking I had fixed it…​ and then finding that my SSH sessions were still having the problem.

Long story short, I finally figured out that the very act of plugging a monitor into the HDMI port was the thing that was fixing the stuttering issue. Argh!

Find the pig!

Watching top wasn’t giving me any clues, so I started to read about other OpenBSD monitoring tools and found systat(1). You can start it up without any parameters and navigate its various views with the left/right arrow keys on your keyboard.

The view I found most useful was "pigs" (processes hogging the CPU), which you can go directly to with:

# systat pigs

When my computer "froze", this is what I saw (one column removed):

   1 users Load 2.27 2.41 2.04  treebeard.local 17:43:00

NAME                     CPU      20\     40\     60\     80\   100\
<idle>                100.00 ######################################
i915-unordered         18.55 ######
drmwq                   8.15 ###
drmwq                   4.74 #
drmwq                   2.69
drmwq                   1.46

Aha! And sure enough, searching for my problem in conjunction with i915 delivered some answers.

systat is a great tool and apparently common to the BSD family in general. This is the stuff I really enjoy learning.

The fix!

The first useful tip I got searching for my issue with the i915 driver was:

Are you intending to run it as a graphical workstation? If not, try "b -c" at the bootloader prompt, then "disable inteldrm" and "quit". That is likely to get it booting - if so, you should be able to get a dmesg. (The on-disk kernel can be edited with "config -ef /bsd").

Which was the whole solution, though I didn’t understand all of it yet.

I tried the suggested commands at the OpenBSD boot> prompt and it worked. My freezing problems went away even without a monitor plugged in.

The second hit contained an explanation for making the fix permanent:

Fix For Latency Issues - It is believed to be related to the Direct Rendering Manager (DRM) overutilizing the CPU which causes the latency spikes.

And here’s the solution:

# cp /bsd /bsd.GENERIC

# echo 'disable inteldrm' >> /etc/bsd.re-config
# config -e -c /etc/bsd.re-config -f /bsd
# reboot

I did not run these instructions blindly. I read the config(8) man page and also the relevant chapter of Michael Lucas’s Absolute OpenBSD book to ensure I understood what the above was doing.

It’s been working for a week

No more troubles running this machine headlessly, yay!

I think the fact that you can edit the running kernel binary like this and test it, then save it to disk without having to recompile anything is super cool. Does the Linux kernel have a similar tool?

OpenBSD continues to impress with its tooling and documentation. This was not a fun problem to debug, but once I had the right keywords to find the fix, the solution was pleasant to understand and implement.