I got a something old something new laptop and installed OpenBSD. And then the murders began.

hardware

It’s an ASUS Zenbook 14 from 2023. Specifically, model UM3402YA because ASUS really likes to make a variety of very different machines with near identical names. After picking up a cheap Vivobook, I decided to reroll for a better screen. I found this model for about $400 at Walmart, though it seems prices have increased.

It’s a laptop as one would expect, not much more to say, except for two features. The CPU is what AMD calls a 7530U, which is pretty deceitful. The naive buyer may reasonably conclude that this is 99.8% as good as a 7540U CPU, but far from it. That’s a load bearing tens digit. This is actually a slightly warmed over 5600U. It’s not a bad CPU, but definitely know that it’s Zen 3 (not Zen 4, not even Zen 3+). The other thing is the screen. 2880x1800 90Hz OLED. It’s fantastic.

install

The OpenBSD install goes smoothly. Fiddle with BIOS, disable all the things, boot from USB. Smash enter.

I think we’re good.

schsio

After rebooting, the system hangs halfway through booting the kernel. I get a screenful of blue text, but it’s clearly stuck somewhere.

Key thing to know about an OpenBSD boot hang is that it’s rarely the last device you see. That one worked. It’s the next one that’s broken. Identifying it requires rebooting with the -c flag at the boot> prompt, then enable verbose booting.

This reveals that the kernel hung probing schsio. Whatever that is. Some sort of onboard sensors hub from a bygone era. Specifically the fourth probe address. Whatever lives at 0x164e on this laptop, it’s not a schsio but it is grumpy.

I can disable this device locally, and things are fine. Until I rebuild a kernel, which I like to do, and then it comes back. After one, two, three, four attempts, I was able to fix (copy the string provided to me) the Makefile to also reconfig the newly built kernel.

Another diff to config let me comment out those lines, which will be helpful soon.

legacy

We want a better fix for the schsio issue. Careful analysis of the robust and extensive OpenBSD telemetry system, dmesglog, didn’t reveal any attachments at 0x164e. Maybe it doesn’t exist. Maybe it never existed. I suggest we can disable this probe, and fix one known system and break zero known systems.

Some other developers have a much better idea. We can skip probing the ISA bus entirely on modern systems. In this case, modern being defined as systems where the ACPI tables (un)set a magic flag, the legacy devices supported flag. If that’s zero, we don’t look at any ISA devices.

This was a small matter of adding a variable to export this flag from here to there, and now I can leave schsio enabled and everything still works.

This change then broke the aforementioned vivobook, however, until some more matches were added.

amdgpio

One last issue I had is that the amdgpio device was constantly interrupting. Thousands and thousands of interrupts. Like a very whiny baby.

It took a few edits and reboots to determine this is what is attached to pin 49.

Without more information at this time, I disabled it the hard way.

diff -u -p -r1.10 amdgpio.c
--- amdgpio.c   20 Oct 2022 20:40:57 -0000      1.10
+++ amdgpio.c   19 May 2025 20:06:32 -0000
@@ -266,6 +266,9 @@ amdgpio_intr_establish(void *cookie, int
 
        KASSERT(pin >= 0 && pin != 63 && pin < sc->sc_npins);
 
+       if (pin == 49)
+               return;
+
        sc->sc_pin_ih[pin].ih_func = func;
        sc->sc_pin_ih[pin].ih_arg = arg;
 

A similar laptop has a similar quirk in the linux kernel.

wmi

Finally, I wanted things like fan and keyboard backlight hotkeys to work.

That led to the WMI adventure.

sound

Well, this doesn’t look. Very low priority for me personally.

results

Everything should be a little bit smoother in the future.