TinyComputers.io (Posts about ubuntu)

The SpacemiT K3 on Mainline Ubuntu: KVM Works, and the BSDs Cannot Boot

A.C. Jokela — Sun, 27 Sep 2026 13:00:00 GMT

In the first piece on this board I said the SpacemiT K3 Pico-ITX was genuinely competitive silicon shipped with a kernel that could not load KVM. I bought it to run virtual machines. It cost \$1,175.09 delivered and modprobe kvm oopsed in jump_label_module_notify.

If you did not read that one, the short version: the K3 Pico-ITX is a RISC-V single board computer with 32 GB of RAM and sixteen cores, split into two groups of eight. Eight X100 cores do ordinary work. Eight A100 cores are an AI engine rated at 60 TOPS. It is the first RISC-V board I have tested that competes with ARM on speed rather than apologising for itself, and at \$1,175.09 it needs to.

Two words will come up constantly here, so they are worth pinning down. The vendor kernel is the Linux that SpacemiT ships, which they maintain themselves and which knows every quirk of their hardware. Mainline is the Linux everyone else gets, where support has been accepted into the official kernel tree. Vendor kernels usually work better and age worse. The interesting moment for any new board is when mainline catches up, because that is when the board stops depending on one company's attention.

Ubuntu 26.10 was the first release where this board's support is upstream rather than carried in SpacemiT's vendor tree. So I flashed EDK2 over the vendor U-Boot, installed Ubuntu, and re-ran everything.

KVM works. That is the headline and it is a real result:

$ sudo modprobe kvm && lsmod | grep kvm
kvm    466944  10
$ ls -l /dev/kvm
crw-rw---- 1 root kvm 10, 232 /dev/kvm

A Debian 13 riscv64 guest boots under -cpu host and inherits the X100's vector and vector-crypto extensions. That h on the end of the ISA string rv64imafdcvh is the hypervisor extension, the optional block of silicon that lets a RISC-V chip run virtual machines at full speed instead of simulating them. The K3 has always had it. Until now no kernel on this board could use it. The board does the thing I bought it for.

Everything else I found is worse than that sentence suggests. Including, first, the part where I could not install it.

Three failed installs and a serial cable

The supported path replaces SpacemiT's bootloader with EDK2, an open implementation of UEFI, the same firmware interface a PC uses to find and start an operating system. Swapping it in is what lets the board boot an ordinary Ubuntu USB stick instead of something hand-assembled for this hardware. The swap happens over fastboot, with the board held in a special flashing mode. The flash is the easy part. Hold the FDL button, apply power to the first USB-C connector, release, and fastboot devices answers. Six partitions get written and edk2.itb lands in the one confusingly named uboot. That worked first time.

The install did not. Three times the board booted the installer, appeared on the network as ubuntu-server, and then sat there. For hours. No reboot, no progress, no way in. The DHCP lease renewed, ICMP answered, port 22 was open and refused every credential. From outside, a working install and a dead one look identical.

I spent a long time constructing theories from that non-evidence. The storage match in my autoinstall config must be wrong. The kernel must not see the UFS. The firmware must have a dangling boot entry. Each theory was plausible, each led to another blind retry, and every one of them was wrong.

What broke the deadlock was a three-wire USB-to-TTL serial adapter on the header silkscreened DEBUG, next to the USB-C connectors. Any 3.3 V adapter works; mine is an older PL2303 and a CP2102 is the better buy today. Whatever you use, it must be 3.3 V TTL and not a true RS-232 cable, which swings to plus and minus twelve volts and will destroy the UART. The board's own device tree tells you where the console goes:

chosen  { stdout-path = "serial0:115200n8"; }
aliases { serial0 = "/soc/serial@d4017000"; }

Thirty seconds after attaching it, the answer was on screen. Two answers, actually.

The first was the UFS error storm described below, saturating an 11.5 KB/s UART with 117 KB of messages every ten seconds. The second was better:

Installer update available
[ Update to the new installer ]
[ Continue without updating   ]

That prompt only appears when autoinstall is not active. Autoinstall is Ubuntu's unattended install mechanism: you leave a configuration file on the media, the installer reads it, and it answers every question for you without a human present. It is how you install a machine that has no screen. My configuration had never been applied on any attempt. Every one of those multi-hour "hangs" was the plain interactive installer, sitting at a prompt, waiting for a keypress from a machine with no keyboard and no screen.

There is a second trap stacked on the first. Because the device tree pins the console to serial, subiquity starts in serial mode and opens with a dialog asking whether you want rich mode or basic mode. It waits. An unattended install on a board whose console is a UART will stop dead at that question, and nothing about it reaches the network.

So I drove the installer over the serial line instead, one keystroke at a time, which is how Ubuntu actually got onto this board. It is worth knowing before you buy a headless RISC-V machine and assume autoinstall will carry you.

Mainline sees half the cores, and not the half you'd hope

Bianbu listed sixteen processors and let a process use one cluster of eight or the other, never both. I assumed a mainline kernel would either fix the partition or at least expose the same hardware.

It does neither:

possible : 0-7
present  : 0-7
online   : 0-7
uarch    : spacemit,x100  (x8)
/proc/set_ai_thread : absent

The A100 cluster is simply not enumerated. Bianbu at least showed all sixteen in /proc/cpuinfo and gave you /proc/set_ai_thread to reach the AI cores. Mainline does not know they exist. The vendor hook is gone with it.

So the AI cores are less accessible on Ubuntu than on Bianbu, not more.

The practical consequence is that the 110-second sixteen-core compile I speculated about in the first piece is not merely blocked, it is unreachable. There is no cluster to schedule onto. The A100 figure from that piece, 342.78 s against the X100's 161.29 s on the same tree, was measured through the vendor's /proc/set_ai_thread hook. That hook does not exist on mainline, so on Ubuntu there is no way to run anything on those cores at all, fast or slow.

One trap worth naming, because I fell into it and reported the wrong answer for a few minutes: taskset -c 0-15 succeeds here. It returns zero and looks like a win. It intersects the mask you asked for with the CPUs that exist and quietly gives you 0-7. Check the resulting affinity, not the exit code.

The compile got slower, and it is not the clock

	Bianbu 6.18.3 (vendor BSP)	Ubuntu 7.3.0 (mainline)
Rust compile, pinned tree, n=3	161.80 s (sd 0.97)	183.43 s (sd 2.12)
sysbench, 1 thread	912.45 ev/s	910.59 ev/s
sysbench, 8 threads	7,245.09 ev/s	7,307.50 ev/s

Same board, same tree at 2821bba, same rustc 1.98.1. Mainline is 13.4% slower on the compile.

My first instinct was thermal throttling, because the three mainline runs climbed steadily (181.0, 184.2, 185.1) where Bianbu's were flat. That instinct was wrong. Single-threaded sysbench is a decent clock proxy and it is identical, within 0.2%. The eight-thread figure is actually 0.9% faster on mainline. Raw CPU throughput has not changed.

So something other than the CPU costs 13% on a compile. The most likely candidate is storage: root moved from the internal UFS to NVMe behind LVM, and a clean cargo build is I/O heavy. I have not proven it, and I am not going to claim a kernel regression I cannot demonstrate.

Two things make this comparison less clean than I would like, and both are worth stating rather than burying:

Mainline exposes no cpufreq policy and no thermal zones for this SoC. On Bianbu the governor was userspace pinned at 2.2 GHz and there were seven thermal zones. On Ubuntu the clock cannot be read, pinned, or checked for throttling.
OpenSSL went from 3.5.5 to 4.0.1 between the two installs, so the crypto numbers are not comparable at all. I am not publishing a vector-crypto delta that is really a library version delta.

The internal storage does not work

The K3 has 119 GB of onboard UFS storage, which is the faster successor to the eMMC chips most single board computers solder down. On mainline it does not exist:

ufshcd-spacemit c0e00000.ufshc: freq-table-hz property not specified
ufshcd-spacemit c0e00000.ufshc: ufshcd_populate_vreg: Unable to find vcc-supply regulator, assuming enabled
ufshcd-spacemit c0e00000.ufshc: DL error event, INT errors:0x4, DL_ERR:0x80000002
  ... ~1600 more error lines ...
ufshcd-spacemit c0e00000.ufshc: ufshcd_async_scan failed: -19

The device tree is a data file the firmware hands the kernel describing what hardware is present and how it is wired: which controller sits at which address, which power rails feed it, what clock speeds it supports. Linux has no other way to discover any of this on a board like the K3. The K3's device tree declares the storage controller at ufshc@c0e00000 but supplies no vcc/vccq regulator entries and no freq-table-hz. The driver assumes the rails are live, the device never answers, and link training fails at the Data Link and PHY Adapter layers until the controller gives up in eh_fatal.

The driver binds correctly, and the alias matches the board exactly (of:N*T*Cspacemit,k3-ufshc against the DTB's compatible = "spacemit,k3-ufshc"). The DTB is simply incomplete. Ubuntu ships and manages that DTB as a package, and I watched update-initramfs print Installing new k3-pico-itx.dtb while blacklisting the driver, so this is fixable upstream without new silicon and without a vendor release.

Until then the internal storage is unusable and root has to live on NVMe. Mine is a WD_BLACK SN850X, which is overkill for a boot disk and was already in the board from the first review. I blacklisted ufs_spacemit, which reclaims about forty seconds of boot and 1,600 error lines.

That error storm is worth dwelling on, because it nearly cost me the whole install. The K3's device tree pins the kernel console to serial0 at 115200, which is about 11.5 KB/s. The UFS failure generates roughly 117 KB of error messages every ten seconds. The machine spends essentially all of its time writing errors to a UART whether or not anything is listening. From the outside it looks exactly like a hang.

The finding I did not expect

I wanted to see the board do real work, so I set out to build four RISC-V guests: Debian, FreeBSD, NetBSD and OpenBSD.

Debian booted under KVM and ran fine. All three BSDs panicked about one second in.

FreeBSD:

panic: Illegal instruction 0xc0002573 at 0xffffffc00042e362
#5 0xffffffc00042e03e at arc4rand+0x8e

NetBSD, independently:

panic: cpu_trap: fatal kernel trap  (va=0xc0002773)

Those two values are the same instruction with a different destination register. Pulling 0xc0002573 apart: the low seven bits are the opcode, 0x73, which on RISC-V means a system instruction. The middle field says it is a CSR read. The top twelve bits are the register number, 0xC00. That register is cycle, a free-running count of CPU clock ticks, and the instruction that reads it is spelled rdcycle.

Both kernels were dying on the same one-instruction question: how many cycles have elapsed?

A detour into who is allowed to do what

To explain why that question is illegal, I need one piece of RISC-V background, and it is the piece that makes everything else in this post make sense.

RISC-V software runs at one of three privilege levels. Machine mode is the most privileged and is where firmware lives: on this board that is SpacemiT's OpenSBI, burned into flash, running before Linux and continuing to sit underneath it forever. Supervisor mode is where the operating system kernel runs. User mode is where your programs run. Each level can see and do strictly less than the one below it.

Crucially, the lower level decides what the upper levels are permitted to touch. Machine-mode firmware holds a register called mcounteren, the counter-enable register, with one bit per hardware counter. Set the bit and everyone above may read that counter. Leave it clear and any attempt to read it is an illegal instruction, exactly as if the CPU did not implement it at all.

So rdcycle failing is not a bug in the CPU, the kernel, or the hypervisor. It is firmware declining to grant permission, and there is nothing any layer above can do about it.

My first theory was still the wrong one. I assumed RISC-V's KVM does not grant guests direct counter access, and that a guest is simply more restricted than its host. Wrong. The host cannot do it either:

$ cat rdcycle.c
int main(void){ unsigned long c; __asm__ volatile("rdcycle %0":"=r"(c)); return 0; }
$ ./rdcycle
Illegal instruction (core dumped)

That is plain userspace on the host, no virtualization anywhere. Testing all three counters:

CSR	K3 host, U-mode
`rdtime`	OK
`rdcycle`	SIGILL
`rdinstret`	SIGILL

The K3's M-mode firmware sets mcounteren.TM but not CY or IR. Nothing above M-mode can read the cycle or instruction counters: not host userspace, not the host kernel, not any guest.

FreeBSD's arc4rand and NetBSD's early init both execute rdcycle. So they panic on this board whether virtualized or not. This is not a KVM limitation and not a BSD bug. Linux is unaffected only because riscv64 Linux goes through SBI and the time CSR instead of reading cycle directly.

I confirmed it the other way too. QEMU can run a guest two ways. KVM uses the host's own CPU to execute guest code directly, which is fast but means the guest inherits the host's hardware, firmware restrictions included. TCG ignores the hardware and simulates a RISC-V processor in software, which is slow but means the simulated CPU behaves the way the specification says rather than the way this board does. Under TCG, which emulates its own machine mode and its own counters, FreeBSD 15.1 and NetBSD 11.99.8 both boot to a root shell without complaint. The images are fine. The board is not.

It is worth being precise about what this is not. NetBSD runs perfectly well on RISC-V: I have installed it on the Milk-V Mars and chased a firmware bug through its page tables on that board. So I ran the same three-counter test on the Pine64 Star64, a JH7110 board sitting on the same bench:

CSR	Star64 (JH7110)	K3 Pico-ITX (SpacemiT K3)
`rdtime`	OK	OK
`rdcycle`	OK	SIGILL
`rdinstret`	OK	SIGILL

Same operating systems, same architecture, same room. The JH7110's firmware grants all three counters and NetBSD boots on it. The K3's grants one. That is the whole difference, and it is a decision made in M-mode firmware rather than anything about RISC-V, NetBSD, or KVM.

One practical note if you try this yourself: BSD guests need virtio-blk-device (MMIO) rather than if=virtio, which gives virtio-blk-PCI. NetBSD does not attach the PCI variant and drops to root device: with only vioif0 offered.

What a guest actually gets

Since the whole point was virtualization, it is worth saying what running a guest on this board is actually like.

The first thing that bites is firmware layering, and it is not documented anywhere obvious. Under KVM the host's OpenSBI already owns M-mode, so the guest must start in supervisor mode. Passing QEMU an M-mode firmware fails outright:

qemu-system-riscv64: Machine mode firmware is not supported in combination with KVM.

The invocation that works is -bios none plus the S-mode U-Boot as the kernel, which then chainloads the guest's own bootloader over EFI. Under TCG the opposite is true: QEMU emulates the entire machine including M-mode, so OpenSBI has to be loaded with -bios default. The same VM definition cannot serve both. I spent a while watching a TCG guest produce absolutely no output because I had carried the KVM arguments over unchanged, and with no M-mode firmware there was nothing to run the S-mode payload.

What the guest sees is better than I expected. With -cpu host, the Debian guest's ISA string comes through as:

rv64imafdcv_zicbom_..._zvkned_zvknha_zvknhb_zvksed_zvksh_zvkt

Those last few are the vector crypto extensions, dedicated instructions for AES, SHA-2, SM4 and SM3. They are why this board pushes 2.37 GB/s of AES-GCM where an older RISC-V board manages 21.7 MB/s. The guest is not seeing a sanitised baseline RISC-V core, it is seeing the X100's actual feature set, which means the AES-GCM throughput that made this board interesting in the first place is available inside a VM. That is the part of this that genuinely works well.

The guest ISA does not carry h, so there is no nested virtualization. That is expected and I would not have used it.

I cannot tell you much about how many guests this board holds, because I never found out. Three reached a shell: Debian under KVM, FreeBSD and NetBSD under TCG. OpenBSD got as far as extracting base78.tgz and never finished, because by then it was clear that every BSD here was going to be an emulated guest and I stopped all three rather than let them grind. With those four QEMU processes up, one of which was only an installer, the host sat at load 2.07 and 5 GB of 31 GB. That is not a capacity test and I am not going to dress it up as one. It says only that the board was nowhere near its limits when I gave up on the experiment.

Which kernel should you actually run

That leaves a question the first piece could not ask, because there was only one option. Now there are two, and neither wins outright.

Bianbu 4.0.4 with the vendor 6.18.3 BSP compiles 13.4% faster, drives the internal 119 GB UFS, exposes cpufreq so the clock can be pinned at 2.2 GHz, reports seven thermal zones, and enumerates all sixteen cores with a documented way to reach the A100 cluster. It cannot load KVM.

Ubuntu 26.10 with mainline 7.3.0 loads KVM and runs accelerated guests. It cannot use the internal storage, shows no clock or temperature at all, and pretends eight of the cores do not exist.

If you bought this board to compile things, the vendor kernel is still the better machine and it is not close. If you bought it to run VMs, which I did, mainline is the only option and you pay for it in storage, visibility and cores.

What makes that trade-off worse than it sounds is that the losses are not symmetric. A slower compile is an inconvenience. Losing the internal storage means the NVMe slot is no longer an expansion option, it is a requirement, and the board's advertised 128 GB becomes decorative. Losing cpufreq and thermal zones means you cannot tell whether a long job is throttling. And losing the A100 cluster removes the 60 TOPS that justify a large part of the \$1,175.09.

I keep coming back to that number. The first piece argued the price was defensible because you get 32 GB, a hypervisor extension and an AI engine. Two of those three now work. The AI engine is reachable only from a kernel that cannot virtualize, which means on any given boot you can have the feature you paid for or the feature you paid for, but not both.

So where does that leave it

I stopped the BSDs. Emulating RISC-V on a RISC-V host defeats the entire point of buying hardware with the hypervisor extension, and a TCG guest on this board is slower than the same guest on a laptop. They were worth building only to find out why they would not run, and that turned out to be the most interesting thing I learned all week.

The honest summary is narrower than "KVM works":

KVM works, for Linux guests. The K3 is a capable Linux hypervisor with a lot of memory. It is also, right now, a hostile host for the BSDs at the firmware level, it cannot use its own internal storage on a mainline kernel, and it hides half its cores from the only kernel that can virtualize properly.

Every one of those is a software or firmware problem rather than a silicon one, which is the same conclusion I reached the first time. The difference is that the list is now specific enough to fix: grant CY and IR in mcounteren, fill in the UFS regulators in the device tree, and describe the A100 cluster upstream.

One more piece to come

Two and a half weeks before this board arrived, I costed a RISC-V rental business in public: two K3 Pico-ITX nodes in a 1U at a Miami colo, roughly \$47 to \$57 per node per month, and a question to readers about whether anyone would actually pay for it. The central pitch was that the hypervisor extension is the one thing you cannot rent from Scaleway or anybody else today.

The best news is that the pitch survives. KVM works, so the differentiator is real rather than theoretical, and the estimate I published without owning the hardware turned out to describe the right machine. The design held up better than I did, too: that plan already budgeted a Raspberry Pi as the BMC holding a USB-UART console to each board, and NVMe drives at about \$120 the pair. Both of those turned out to be exactly the things this week proved you cannot run this board without.

What changes is subtler and mostly unflattering. Renting virtual machines forces the mainline kernel, and on mainline the 128 GB of onboard storage in that \$399 board specification is dead weight, because the UFS controller never links. You are paying for storage you cannot use. The BSD finding removes a customer segment that a RISC-V rental should have been well placed to serve. And mainline reports no clock and no temperature at all, which means a tenant asking whether their node is throttling gets an honest shrug. A BMC can power-cycle a wedged board, but it cannot report numbers the kernel refuses to collect.

There is one operational gap worth designing around. The BMC switches 12 V and watches the console, which covers a hung node. It does not cover firmware recovery, because entering flash mode on this board means holding a physical button while power is applied. That is a GPIO line and a bit of wiring rather than a flight to Miami, but it is not in the current design and I only know it matters because I spent this week needing it.

I want a few more weeks of uptime before I redo those numbers. The next piece will be that arithmetic revisited by someone who now owns the hardware instead of estimating it.

Caveats. The compile comparison has an unresolved 13% gap with a confirmed-identical CPU throughput on both sides; root storage differs between the two installs and is the leading suspect. Clocks could not be pinned or verified on mainline because no cpufreq policy is exposed. Crypto figures are not compared across installs because the OpenSSL version changed. The A100 cluster was not benchmarked because mainline does not enumerate it. The virtualization experiment was abandoned rather than completed: three guests reached a shell, OpenBSD's install was stopped part-way, and no attempt was made to find out how many guests the board will hold. All raw data is in the benchmark repository.

The SpacemiT K3: RISC-V Finally Competes, and the Vendor Kernel Gets in the Way

A.C. Jokela — Fri, 25 Sep 2026 13:00:00 GMT

Every RISC-V board I have reviewed here has needed an excuse. The Pine64 Star64 compiles Rust slower than a quad Cortex-A53 from 2012. The MangoPi MQ Pro takes two hours and ten minutes to do what a Raspberry Pi 5 does in seventy-seven seconds. The Orange Pi RV2 spends eight cores losing to four. The reviews all end the same way: buy it because it is RISC-V, not because it is good.

The SpacemiT K3 Pico-ITX does not need that excuse. It compiles the benchmark in 161.80 seconds, which puts it seventh of thirteen boards on my bench and ahead of the Banana Pi CM5-Pro. It pushes 2,372 MB/s of AES-128-GCM, beating the Cortex-A76 in a Rockchip RK3588. On SHA-512 it is 1.72x faster than that A76. A single SpacemiT X100 core scores 94% of an A76 on sysbench.

This is the first RISC-V machine I have tested that competes on the merits.

It also cost \$1,175.09 delivered, cannot schedule a single job across more than 8 of its 16 cores, and cannot run a virtual machine at all, which is the specific thing I bought it for.

"RVA23 Profile Chip" on the box is the part that matters. RVA23 is the RISC-V application profile that mandates the vector extension and the vector crypto suite, which is exactly why this board's ISA string is so much richer than every other RISC-V machine on my bench.

What it cost

I am putting this near the top because every other review of frontier RISC-V hardware buries it.

The board was \$889 for the 32 GB RAM and 128 GB storage configuration, \$45 shipping, and then \$241.09 in customs duty collected by DHL four days later. That duty is 27.1% on top of the order and appears on no spec sheet or product page.

Origin HKG, shipped by Firefly Technology out of Tsing Yi. Declared contents: "plastic main board for to drive display", 0.85 kg. That declaration is what the \$241.09 got assessed against.

A Raspberry Pi 5 with 8 GB currently sells for around \$200 on Amazon, not the \$80 I quoted in older reviews here. So the honest multiple is roughly 5.9x the price for a board with four times the RAM, twice the cores on paper, vector crypto, PCIe, an NVMe slot and a hypervisor extension. It is not a \$1,095 difference in value, but it is also not the 15x gouging that a stale MSRP comparison would suggest.

The hardware

Pico-ITX, under the acrylic cover it ships with. Two M.2 slots, a coin-cell RTC, an eDP header, and MAC address stickers on the right.

The port edge: two USB-C, four USB-A, gigabit Ethernet, and an SFP cage on the right. Only the gigabit port had a link during testing.

Component	Specification
SoC	SpacemiT K3
CPU	16 cores enumerated: 8x Spacemit X100 @ 2.2 GHz, 8x Spacemit A100 @ 1.8 GHz
ISA	`rv64imafdcvh` plus Zba/Zbb/Zbc/Zbs, V (vector, `vlen:256`), H (hypervisor)
Vector crypto	Zvkned, Zvknha, Zvknhb, Zvksed, Zvksh, Zvkg, Zvbb, Zvbc
RAM	32 GB
Storage	119 GB onboard UFS, plus an NVMe slot
GPU	PowerVR B-Series BXM-4-64 MC1, DRM nodes present
Network	Gigabit, link up on `end0`
OS as shipped	Bianbu 4.0.4, kernel 6.18.3-generic

That ISA string is the most complete of any RISC-V board I have tested, and by a wide margin. Every previous one was rv64imafdc with nothing above baseline. This one has vectors, bit manipulation, the full vector crypto suite, and the hypervisor extension.

I parsed it with the rv64 prefix stripped before matching single letters, because a naive substring search finds the v in rv64 and reports a vector unit that is not there. That mistake cost me an hour on the Star64.

As shipped, plus the NVMe I added. Note the sixteen cores it reports, and hold that thought.

Compiling Rust

The workload is a clean release build of ballistics-engine, three runs after cargo clean, in two tiers: the pinned tree at commit 2821bba that every archived fleet result used, and current HEAD at b0cfcd4.

Pinned tier (2821bba, 16,639 LOC, 144 crates):

Run	Time
1	160.68 s
2	162.41 s
3	162.30 s
Mean	161.80 s (sigma 0.97, 0.60% CV)

HEAD tier (b0cfcd4, 155,867 LOC, 243 crates):

Run	Time
1	1271.27 s
2	1273.18 s
3	1271.06 s
Mean	1271.84 s (sigma 1.16, 0.09% CV)

A 0.09% coefficient of variation across three twenty-one minute builds is the tightest result on my bench. Nothing on this board wobbles: the governor is userspace pinned at maximum, both clusters hold their clocks, and there is no thermal headroom being negotiated.

Left: the pinned-tree fleet. The K3 appears twice because its two clusters are, in practice, two separate eight-core machines. The MangoPi MQ Pro is omitted at 7,824 s, which is 48x the next slowest board and would flatten the chart. Right: single-thread crypto throughput, linear scale, three platforms.

The generational comparison is the cleanest number here. The Orange Pi RV2 runs SpacemiT's previous Ky X1 and takes 650.60 s on the same tree with the same rustc 1.98.1. The K3 does it in 161.80. That is 4.02x faster from the same vendor, one generation later.

Against ARM it is a tie rather than a win. 161.80 s versus the Banana Pi CM5-Pro's 167.15 s is a 3% margin, which I would not defend as a victory. But a RISC-V board landing within noise of an eight-core ARM part is new.

Cryptography, where it actually wins

Single-thread OpenSSL 3.5.5, 16 KB blocks:

Algorithm	SpacemiT K3	RK3588 Cortex-A76	Pine64 Star64	vs A76	vs Star64
AES-128-GCM	2372.7	2185.7	21.7	1.09x	109x
AES-256-GCM	1853.0	1763.9	17.9	1.05x	104x
SHA-256	1520.6	1429.4	35.4	1.06x	43x
SHA-512	646.8	376.1	63.5	1.72x	10x
AES-128-CBC	1622.7	1831.8	31.4	0.89x	52x
ChaCha20-Poly1305	372.4	674.4	51.0	0.55x	7x

A RISC-V board beating a Cortex-A76, the one in an Orange Pi 5 Max, on AES-GCM, SHA-256 and SHA-512 has not happened before on this bench.

Isolating the extensions makes the mechanism obvious. Restricting OPENSSL_riscvcap to plain rv64gc disables the vector crypto fast paths:

Algorithm	Full detection	`rv64gc` only	Gain
AES-128-GCM	2373.3 MB/s	68.8 MB/s	34.5x
AES-256-GCM	1854.3 MB/s	56.7 MB/s	32.7x
SHA-256	1520.0 MB/s	146.1 MB/s	10.4x
SHA-512	646.8 MB/s	270.6 MB/s	2.4x

Strip the extensions and this board performs like every other RISC-V machine I have tested. That 68.8 MB/s figure is in the same league as the Star64's 21.7. The silicon is not what changed; the instruction set is.

The two losses are informative rather than embarrassing. Zvkned and Zvknh accelerate AES and SHA specifically, so ChaCha20 gets nothing from them and falls behind a chip whose general SIMD is better tuned in OpenSSL. If you are terminating TLS on this board, prefer AES-GCM, which is the opposite of the advice I gave for the Star64.

Asymmetric work is unremarkable: RSA-2048 at 245 signs/s, ECDSA P-256 at 4,437 signs/s. Nobody accelerates those in silicon here.

You get eight cores at a time, never sixteen

This is the finding that changes how you should read every number above. I got it wrong twice before I got it right, so here is the whole path.

/proc/cpuinfo lists sixteen processors. Eight report model name: Spacemit(R) X100 and eight report Spacemit(R) A100, with distinct marchid and mimpid values. The boot log says smp: Brought up 1 node, 16 CPUs. The possible, present and online masks all read 0-15.

And then:

nproc                          : 8
PID 1 Cpus_allowed_list        : 0-7
taskset -c 8 <anything>        : failed to set affinity: Invalid argument
cpu8 jiffies after a 3s burn   : 0
cpu0 jiffies after a 3s burn   : 301

My first reading was that the vendor kernel was hiding half the machine. My second reading, after actually looking up what an A100 is, was that the A100 cluster is a 60 TOPS AI engine that merely happens to be built from RISC-V harts, so nproc returning 8 is correct and there is nothing to complain about.

Both readings are wrong, and the truth is more annoying than either.

The A100 cores are reachable. You write a PID to /proc/set_ai_thread, which is world-writable, and that thread's affinity mask flips from 0-7 to 8-15. The setting is inherited by children, so it is enough to do it once in a shell and then run whatever you like. taskset works normally afterwards, within the new mask. That is why plain taskset -c 8 fails as root: the affinity mask is not the door, but there is a door.

And once you are through it, the A100 cores run ordinary code perfectly well. Not AI kernels. Not vector math. rustc.

Rust clean release build, pinned tree 2821bba, cargo -j8, n=2:

  X100 cluster (cpu0-7,  2.2 GHz) : 161.58 s, 161.00 s   mean 161.29 s
  A100 cluster (cpu8-15, 1.8 GHz) : 344.32 s, 341.23 s   mean 342.78 s

The A100 cluster compiles the same tree 2.13x slower than the X100 cluster. Correct for the 2.2 versus 1.8 GHz clock difference and the A100 cores land at 57.5% of X100 per-clock throughput. sysbench, a completely different workload, puts the same figure at 57.4% (428 events/s against 912 single-threaded, 3,430 against 7,245 across eight). Two unrelated benchmarks agreeing to a tenth of a point is about as solid as this kind of measurement gets.

So these are not accelerator lanes that cannot run general code. They are eight real, if unexceptional, RISC-V application cores, roughly 57% the per-clock performance of the big ones, that SpacemiT has tuned for AI work by giving them 1024-bit vectors instead of the X100's 256-bit.

Here is the actual problem. You cannot have both clusters at once. After opting in, taskset -pc 0-15 fails:

taskset: failed to set pid 56055's affinity: Invalid argument
pid 56055's current affinity list: 8-15

0-7 or 8-15. Never 0-15. No process on this machine can be scheduled across all sixteen cores, so no single job can use the whole chip. That is why the compile pinned to cpu0-7 finished in 161.14 s against 161.80 s for the nominally sixteen-core run: the nominally sixteen-core run was always an eight-core run, because sixteen-core runs do not exist here.

What that costs is easy to bound. Summing the two clusters' throughput puts a hypothetical combined build at about 110 seconds, roughly 1.47x faster than the X100 cluster alone. Treat that as a ceiling rather than a prediction, because this build's serialised LTO link would eat into it and cross-cluster scheduling on a chip this asymmetric is not free. But the gap between 161 s and something near 110 s is real compute, sitting in the same coherence domain, fenced off by software.

I am not sure whether the fence is deliberate product design, a limitation of the vendor scheduler patches, or a hardware constraint I cannot see from userspace. SpacemiT's marketing splits the chip into "130K DMIPS of general-purpose compute and 60 TOPS of AI compute", which suggests they think of the two clusters as separate products that happen to share a die. That is a defensible way to build a chip. It is a poor way to describe one, because nothing on the board, in fastfetch, or in the shipped OS tells you any of this. You find out by pinning a compile to cpu8-15 and getting a 0.016 second result.

The one A100 claim I still cannot check is the interesting one: SpacemiT's IME2 llama.cpp build reportedly puts the A100 cluster ahead of X100 on token generation, which is the entire point of those 1024-bit vectors. That needs their runtime and a proper model, and it belongs in its own piece.

Geekbench makes the same mistake I made first, which is some comfort. I uploaded a run as Geekbench 7 result 466791: 363 single-core, 2019 multi-core under Geekbench 7.0.0 Preview for Linux RISC-V. Its system panel reports "1 Processor, 16 Cores", labels the whole chip Spacemit(R) X100, and then gives up with "Cluster 1: 0 Cores". That is detection logic meeting a topology it has no model for.

The scores contradict the topology it printed. Multi-core comes in at 5.56x single-core, and the Clang subtest at 6.43x. Those are eight-core scaling factors, measured on the eight cores Geekbench was allowed to touch.

The benchmark's own blind spot

While measuring this I found a flaw in my own workload that applies to every board I have tested.

The project's release profile sets lto = true and codegen-units = 1, which forces the final crate through a single-threaded link. Parallel efficiency on the K3 falls from 46% on the pinned tree to 22% on HEAD, because HEAD's final crate is much larger and the serial portion grows faster than the parallel one.

That penalises wide machines. A four-core board loses little to a serial link; an eight or sixteen-core board idles through it. Every board ran the identical profile so the fleet numbers remain comparable to each other, but they measure "compile this specific LTO-heavy project" rather than general compile throughput. The K3 is the first machine wide enough to make that visible, and I should have caught it sooner.

Thermals, memory, storage

Nothing dramatic, which is itself worth reporting.

Seven thermal zones sit at 51 to 56 C idle. Under 120 seconds of sixteen-worker stress-ng the hottest cluster peaked at 65 C and both clusters held full clock throughout. No throttling.

The reason the thermal numbers look good: an aluminium heatsink with an integrated blower fan, bolted to the board. No other RISC-V board in this comparison ships with active cooling.

Worth being precise about why: this board is actively cooled. It ships with a substantial aluminium heatsink and a blower fan bolted to the underside, which is not something any other RISC-V board in this comparison has. Holding 65 C under full load is a good result, but it is a good result with a fan, not in spite of having none.

Memory measured 32,468 MB/s read and 23,768 MB/s write. The onboard UFS does 903 MB/s buffered read via hdparm, 238 MB/s write and 932 MB/s read by dd.

I also fitted a WD_BLACK SN850X 2 TB in the NVMe slot, which does 1.0 GB/s write and 2.1 GB/s read. That is a different universe from the microSD-bound RISC-V boards I have reviewed, where the Star64 managed 22.4 MB/s because its controller never leaves SD high-speed mode.

KVM is broken

I bought this board to run virtual machines. Thirty-two gigabytes of RAM and a hypervisor extension is a credible small virtualization host, and RISC-V finally having RVH 1.0 with AIA and an IOMMU is the reason to care about the K3 over anything else on this list.

It does not work.

The ISA string advertises h. The kernel ships CONFIG_KVM=m. Loading the module produces a kernel oops:

Unable to handle kernel paging request at virtual address ffffffff81a0f1c0
Oops [#1]
CPU: 5 UID: 0 PID: 55989 Comm: modprobe Not tainted 6.18.3-generic #1.0.5.4
Hardware name: SpacemiT K3 Pico ITX (DT)
epc : jump_label_module_notify+0x1de/0x368
      load_module+0x15d4 -> blocking_notifier_call_chain_robust -> notifier_call_chain

The fault is in the static-key relocation path during module load, so /dev/kvm is never created and no virtual machine can start. This is a software defect in Bianbu's kernel build, not a hardware limitation: SpacemiT's own materials describe RVH 1.0, AIA and IOMMU support, and K3 KVM work has been landing upstream.

Do not buy this board expecting to run VMs on the image it ships with.

Who this is for

Buy it if you are doing RISC-V platform work and need real hardware that does not make you wait: a build machine, a CI runner, a place to port and profile software where the compile times are tolerable and the crypto is genuinely fast. On those terms it is the first RISC-V board I would actually choose rather than tolerate.

Do not buy it if you want the virtualization host its spec sheet promises, at least not yet, and not on Bianbu. Do not buy it as a compile box either: a \$200 Raspberry Pi 5 does the same tree 2.11x faster, and nothing here changes that. The case for the price is the 32 GB of RAM and the 60 TOPS AI engine, and this review tests neither.

The honest summary is that SpacemiT built genuinely competitive silicon and shipped it with a kernel that cannot load KVM. The hardware is ready. The software is not, and the documentation is worse than the software.

What is broken, restated plainly

Because these are the things that will cost you time if you buy one:

KVM does not work on the SpacemiT-provided kernel. modprobe kvm oopses in jump_label_module_notify on Bianbu 4.0.4 with kernel 6.18.3-generic #1.0.5.4. The hardware supports RVH 1.0; the shipped kernel cannot use it. If virtualization is why you are buying this board, you cannot use the image it arrives with.
No process can use more than 8 of the 16 cores. The A100 cluster is reachable by writing a PID to /proc/set_ai_thread, and those cores run ordinary code at 57.5% of X100 per-clock throughput. But the mask is 0-7 or 8-15, never 0-15, so the whole chip is never available to one job. Every other benchmark here was produced by the eight X100 cores.
A newer BSP kernel did not help. I installed 6.18.3-1.0.8.4 from the porting repo and tried to boot it with kexec. The board did not come back and needed a power cycle. Notably, kexec also failed with a kernel that unquestionably has full K3 support, which suggests kexec itself is unreliable on this vendor firmware rather than the kernel being at fault.
Ubuntu's generic 7.0.0 kernel is not a workaround. It carries one spacemit config entry against the BSP's sixty-six, ships no K3 device trees, and lacks the dwmac-spacemit-ethqos driver this board's network port needs. Booting it would produce an unreachable machine.
The customs duty is real. \$241.09 on a \$934 order, payable on delivery.

A follow-up is coming

Canonical officially supports the SpacemiT K3 starting with Ubuntu 26.10 "Stonking Stingray", and that is the interesting thread to pull. The supported path replaces SpacemiT's U-Boot with EDK2 UEFI firmware, flashed over fastboot with the board in FDL mode, and then installs Ubuntu from a USB stick.

The reason I think it will matter: Ubuntu 26.10 ships kernel 7.3.0, and the mainline SpacemiT device tree pull request that adds K3 support was titled RISC-V SpacemiT Devicetrees for v7.3. That is the first kernel where this board's support is upstream rather than carried in a vendor tree. It is the obvious candidate to fix the KVM oops, which is a kernel-side failure rather than a silicon one.

I have the 26.10 daily image written to a USB stick and the flashing procedure mapped out. The next piece will cover whether official Ubuntu turns this from a fast compile box into the virtualization host it was supposed to be, and whether a mainline kernel lets one process schedule across all sixteen cores instead of eight.

By the numbers:

Rust clean release build, pinned tree (2821bba, 16,639 LOC): 161.80 s mean, 7th of 13 on my bench
Rust clean release build, current tree (b0cfcd4, 155,867 LOC): 1271.84 s mean, 0.09% CV
vs SpacemiT's own previous generation: 4.02x faster than the Ky X1 in the Orange Pi RV2
Single X100 core: 911 sysbench events/s, 94% of a Cortex-A76 at 2.35 GHz
Geekbench 7: 363 single-core, 2019 multi-core (result 466791)
AES-128-GCM 2372.7 MB/s, ahead of a Cortex-A76 and 109x the Pine64 Star64
Vector crypto contribution: 34.5x on AES-128-GCM, 10.4x on SHA-256
Cores usable by one process: 8 of 16, either cluster but never both
A100 cluster on the same compile: 342.78 s against X100's 161.29 s, 57.5% of X100 per clock
KVM: broken, kernel oops on module load
Thermals: 51 C idle, 65 C peak under sixteen-worker load, no throttling
NVMe: 1.0 GB/s write, 2.1 GB/s read
Cost: \$1,175.09 delivered, including \$241.09 customs duty

Caveats. Every figure except the A100 compile and sysbench runs comes from the eight X100 cores. The A100 numbers are n=2 on the compile and single runs on sysbench. I did not test the A100 cluster on AI workloads at all, which is what it exists for, so its 60 TOPS rating remains SpacemiT's number rather than a measurement of mine. The compile workload uses lto = true and codegen-units = 1, which serialises the final link and understates wide machines. Commit 2821bba predates the project having a Cargo.lock, so dependency versions resolve fresh. Network throughput was not measured. The sysbench comparison against the Cortex-A76 uses version 1.0.20 on both boards; the Star64 shipped 0.4.12 and its sysbench figures are not comparable to either.

Review Date: September 25, 2026

Hardware Tested: SpacemiT K3 Pico-ITX, 32 GB RAM, 128 GB UFS, WD_BLACK SN850X 2 TB NVMe added

OS Tested: Bianbu 4.0.4, kernel 6.18.3-generic #1.0.5.4

Benchmark Workload: ballistics-engine clean release builds at commits 2821bba and b0cfcd4, rustc 1.98.1

Conclusion: The first RISC-V board that competes with ARM on performance rather than on novelty, sold at a price that is defensible only if you need what it uniquely offers, and shipped with a kernel that disables half its cores and cannot start a virtual machine.

Upgrading ROCm 7.0 to 7.2 on AMD Strix Halo (gfx1151)

A.C. Jokela — Wed, 18 Feb 2026 16:00:00 GMT

Introduction

If you're running AMD's Strix Halo hardware -- specifically the Ryzen AI MAX+ 395 with its integrated Radeon 8060S GPU -- you already know the software ecosystem is a moving target. The gfx1151 architecture sits in an awkward spot: powerful hardware that isn't officially listed on AMD's ROCm support matrix, yet functional enough to run real workloads with the right driver stack. When ROCm 7.2 landed in early 2026, upgrading from 7.0.2 was a priority. The newer stack brings an updated HSA runtime, a refreshed amdgpu kernel module, and broader compatibility improvements that matter on bleeding-edge silicon.

This post documents the complete upgrade procedure from ROCm 7.0.2 to 7.2 on a production Ubuntu 24.04 system. It's not a theoretical exercise -- this was performed on a live server running QEMU virtual machines and network services, with the expectation that everything would come back online after a single reboot.

AMD's official documentation states that in-place ROCm upgrades are not supported. The recommended path is a full uninstall followed by a clean reinstall. That's exactly what we did, and the entire process took about 20 minutes of wall-clock time (excluding the reboot).

System Overview

The target system is a Bosgame mini PC running the Ryzen AI MAX+ 395 APU. If you've read the earlier review of this hardware, you'll be familiar with the specs. For context on this upgrade, here's what matters:

Hardware

CPU: AMD Ryzen AI MAX+ 395, 16 cores / 32 threads, Zen 5
GPU: Integrated Radeon 8060S, 40 Compute Units, RDNA 3.5 (gfx1151)
Memory: 32 GB DDR5, unified architecture with 96 GB allocatable to GPU
Peak GPU Clock: 2,900 MHz

Software (Pre-Upgrade)

OS: Ubuntu 24.04.3 LTS (Noble Numbat)
Kernel: 6.14.0-37-generic (HWE, pinned)
ROCm: 7.0.2
amdgpu-dkms: 6.14.14 (from repo.radeon.com/amdgpu/30.10.2)
ROCk Module: 6.14.14

Running Services

The system was actively serving several roles during the upgrade:

Five QEMU virtual machines (three x86, two aarch64)
A PXE boot server (dnsmasq) for the local network
Docker daemon with various containers

None of these services are tied to the GPU driver stack, so the plan was to perform the upgrade and reboot without shutting them down first. The VMs and network services would come back automatically after the reboot.

Why Upgrade

ROCm 7.0.2 worked on this hardware. Models loaded, inference ran, rocminfo detected the GPU. So why bother upgrading?

Three reasons:

Driver maturity for gfx1151: The amdgpu kernel module jumped from 6.14.14 to 6.16.13 between the two releases. That's not a minor revision -- it represents months of kernel driver development. On hardware that isn't officially supported, newer drivers tend to bring meaningful stability improvements as AMD's internal teams encounter and fix issues on adjacent architectures.
HSA Runtime improvements: ROCm 7.2 ships HSA Runtime Extension version 1.15, up from 1.11 in ROCm 7.0.2. The HSA (Heterogeneous System Architecture) runtime is the lowest layer of the ROCm software stack -- it handles device discovery, memory management, and kernel dispatch. Improvements here affect everything built on top of it.
Ecosystem alignment: PyTorch wheels, Ollama builds, and other ROCm-dependent tools increasingly target 7.2 as the baseline. Running 7.0.2 was becoming an exercise in version pinning and compatibility workarounds.

The Kernel Hold: Why It Matters

Before diving into the procedure, a note on kernel management. This system runs the Ubuntu HWE (Hardware Enablement) kernel, which provides newer kernel versions on LTS releases. At the time of this upgrade, the HWE kernel was 6.14.0-37-generic. The upstream kernel had already moved to 6.17, but we didn't want the ROCm upgrade to pull in a kernel that AMD's DKMS module might not build against.

The solution is apt-mark hold:

sudo apt-mark hold linux-generic-hwe-24.04 linux-headers-generic-hwe-24.04 linux-image-generic-hwe-24.04

This prevents apt from upgrading the kernel meta-packages, effectively pinning the system to 6.14.0-37-generic. The hold was already in place before the upgrade and remained untouched throughout. After the upgrade, we confirmed it was still active:

apt-mark showhold

linux-generic-hwe-24.04
linux-headers-generic-hwe-24.04
linux-image-generic-hwe-24.04

If you're running Strix Halo or any other hardware where kernel compatibility with amdgpu-dkms is uncertain, kernel holds are essential. A kernel upgrade that breaks the DKMS build means no GPU driver after reboot.

Upgrade Procedure

Step 1: Uninstall the Current ROCm Stack

AMD provides the amdgpu-uninstall script for exactly this purpose. It removes all ROCm userspace packages and the amdgpu-dkms kernel module in a single operation:

sudo amdgpu-uninstall -y

This command removed approximately 120 packages, including the full HIP runtime, rocBLAS, MIOpen, MIGraphX, ROCm SMI, the LLVM-based compiler toolchain, and the Mesa graphics drivers that ship with ROCm. The DKMS module was purged, which means the amdgpu kernel module was removed from the 6.14.0-37-generic kernel's module tree.

After the ROCm stack was removed, we purged the amdgpu-install meta-package itself:

sudo apt purge -y amdgpu-install

This also cleaned up the APT repository entries that amdgpu-install had configured in /etc/apt/sources.list.d/. The old repos -- repo.radeon.com/amdgpu/30.10.2, repo.radeon.com/rocm/apt/7.0.2, and repo.radeon.com/graphics/7.0.2 -- were all removed automatically.

Step 2: Clean Up Leftover Files

The package removal was thorough but not perfect. A few leftover directories remained in /opt/:

ls /opt/ | grep rocm

rocm-7.0.0
rocm-7.0.2
rocm-7.9.0

The rocm-7.0.0 directory was from a previous installation attempt. The rocm-7.9.0 was from an earlier experiment with a release candidate build. The rocm-7.0.2 directory contained a single orphaned shared library (libamdhip64.so.6) that dpkg couldn't remove because the directory wasn't empty. All three were cleaned up manually:

sudo rm -rf /opt/rocm-7.0.0 /opt/rocm-7.0.2 /opt/rocm-7.9.0

It's worth checking for stale ROCm directories after any uninstall. They consume negligible disk space but can confuse build systems and scripts that scan /opt/rocm* for active installations.

Step 3: Install the ROCm 7.2 Installer

AMD distributes ROCm through a meta-package called amdgpu-install. Each ROCm release has its own version of this package, which configures the appropriate APT repositories. The 7.2 installer was downloaded directly from AMD's repository:

cd /tmp
wget https://repo.radeon.com/amdgpu-install/7.2/ubuntu/noble/amdgpu-install_7.2.70200-1_all.deb
sudo apt install -y ./amdgpu-install_7.2.70200-1_all.deb
sudo apt update

After installation and apt update, three new repositories were active:

https://repo.radeon.com/amdgpu/30.30/ubuntu noble -- the kernel driver and Mesa components
https://repo.radeon.com/rocm/apt/7.2 noble -- the ROCm userspace stack
https://repo.radeon.com/graphics/7.2/ubuntu noble -- graphics libraries

The version numbering can be confusing. The amdgpu-install package version is 30.30.0.0.30300000-2278356.24.04, which maps to the amdgpu driver release 30.30. The ROCm version is 7.2.0. These are different version tracks that AMD maintains in parallel.

Step 4: Install ROCm 7.2

With the repositories configured, the actual installation was a single command:

sudo amdgpu-install -y --usecase=graphics,rocm

The --usecase=graphics,rocm flag tells the installer to include both the Mesa graphics drivers and the full ROCm compute stack. This is the right choice for a system that needs both display output and GPU compute capabilities.

The installation took approximately 10 minutes and included:

amdgpu-dkms 6.16.13: The kernel module, compiled via DKMS against the running kernel
Full ROCm 7.2 stack: HIP runtime, hipcc compiler, rocBLAS, rocFFT, MIOpen, MIGraphX, RCCL, ROCm SMI, ROCProfiler, and dozens of other libraries
Mesa graphics: Updated EGL, OpenGL, and Vulkan drivers from the amdgpu Mesa fork
ROCm LLVM toolchain: The LLVM-based compiler infrastructure that HIP uses for kernel compilation

The DKMS build is the critical step. During installation, DKMS compiled the amdgpu module against the kernel headers for 6.14.0-37-generic. The output confirmed a successful build:

depmod...
update-initramfs: Generating /boot/initrd.img-6.14.0-37-generic

The initramfs was regenerated to include the new module, ensuring it would be loaded at boot.

Step 5: Verify DKMS

Before rebooting, we confirmed the DKMS status:

dkms status

amdgpu/6.16.13-2278356.24.04, 6.14.0-37-generic, x86_64: installed
virtualbox/7.0.16, 6.14.0-36-generic, x86_64: installed
virtualbox/7.0.16, 6.14.0-37-generic, x86_64: installed
virtualbox/7.0.16, 6.8.0-100-generic, x86_64: installed

The new amdgpu module (6.16.13) was built and installed for 6.14.0-37-generic. Note that it only built for the currently running kernel, unlike VirtualBox which had modules built for older kernels as well. This is expected -- DKMS builds against available kernel headers, and the old kernel headers for 6.14.0-36 and 6.8.0-100 were still present from earlier installations.

Step 6: Reboot

sudo reboot

The server came back online in approximately 50 seconds.

Post-Reboot Verification

rocminfo

The first check after reboot was rocminfo, which queries the HSA runtime for available agents:

rocminfo

ROCk module version 6.16.13 is loaded
=====================
HSA System Attributes
=====================
Runtime Version:         1.18
Runtime Ext Version:     1.15
...
==========
HSA Agents
==========
Agent 1: AMD RYZEN AI MAX+ 395 w/ Radeon 8060S (CPU)
Agent 2: gfx1151 (GPU)
  Marketing Name:          AMD Radeon Graphics
  Compute Unit:            40
  Max Clock Freq. (MHz):   2900
  Memory Properties:       APU
  ISA 1: amdgcn-amd-amdhsa--gfx1151
  ISA 2: amdgcn-amd-amdhsa--gfx11-generic

Key observations:

ROCk module 6.16.13: The new kernel module loaded successfully.
Runtime Ext Version 1.15: Upgraded from 1.11 in ROCm 7.0.2.
gfx1151 detected: The GPU was recognized with its correct ISA identifier.
gfx11-generic ISA: ROCm 7.2 also exposes a generic gfx11 ISA, which allows software compiled for the broader RDNA 3 family to run on this device without gfx1151-specific builds.
APU memory: The memory properties correctly identify this as an APU with unified memory.

ROCm SMI

rocm-smi

Device  Node  Temp    Power     SCLK  MCLK     Fan  Perf  VRAM%  GPU%
0       1     33.0C   9.087W    N/A   1000Mhz  0%   auto  0%     0%

The GPU was visible and reporting telemetry. The 0% VRAM reading is expected on an APU -- rocm-smi reports dedicated VRAM usage, but on a unified memory architecture, GPU memory allocations come from system RAM and aren't reflected in this counter.

ROCm Version

cat /opt/rocm/.info/version

7.2.0

DKMS

dkms status

Confirmed amdgpu/6.16.13 remained installed for 6.14.0-37-generic after reboot.

PyTorch Validation

With the driver stack verified, the next step was confirming that PyTorch could see and use the GPU. ROCm 7.2 ships with prebuilt PyTorch wheels on AMD's repository.

Installing PyTorch for ROCm 7.2

We set up a Python virtual environment and installed the ROCm-specific wheels:

python3 -m venv .venv
source .venv/bin/activate
pip install --upgrade pip

The PyTorch wheel for ROCm 7.2 requires a matching ROCm-specific build of Triton. Both are available from AMD's manylinux repository. The order matters -- Triton must be installed first, since the PyTorch wheel declares it as a dependency with a specific version that doesn't exist on PyPI:

pip install https://repo.radeon.com/rocm/manylinux/rocm-rel-7.2/triton-3.5.1%2Brocm7.2.0.gita272dfa8-cp312-cp312-linux_x86_64.whl
pip install https://repo.radeon.com/rocm/manylinux/rocm-rel-7.2/torch-2.9.1%2Brocm7.2.0.lw.git7e1940d4-cp312-cp312-linux_x86_64.whl
pip install https://repo.radeon.com/rocm/manylinux/rocm-rel-7.2/torchvision-0.24.0%2Brocm7.2.0.gitb919bd0c-cp312-cp312-linux_x86_64.whl

These are the ROCm 7.2 builds for Python 3.12. AMD also provides wheels for Python 3.10, 3.11, and 3.13.

Smoke Test

import torch
print("PyTorch:", torch.__version__)
print("CUDA available:", torch.cuda.is_available())
print("Device:", torch.cuda.get_device_name(0))
print("VRAM:", round(torch.cuda.get_device_properties(0).total_memory / 1e9, 1), "GB")

PyTorch: 2.9.1+rocm7.2.0.git7e1940d4
CUDA available: True
Device: AMD Radeon Graphics
VRAM: 103.1 GB

PyTorch detected the GPU through ROCm's HIP-to-CUDA translation layer. The 103.1 GB figure represents the total addressable memory on this unified-memory APU, which includes both the 96 GB GPU allocation and additional system memory accessible through the HSA runtime.

Note the use of torch.cuda despite this being an AMD GPU. ROCm's HIP runtime presents itself through PyTorch's CUDA interface, so all CUDA API calls in PyTorch (device selection, memory management, kernel launches) work transparently with AMD hardware.

Before and After Summary

Component	ROCm 7.0.2	ROCm 7.2.0
ROCm Version	7.0.2	7.2.0
amdgpu-dkms	6.14.14	6.16.13
ROCk Module	6.14.14	6.16.13
HSA Runtime Ext	1.11	1.15
amdgpu Repo	30.10.2	30.30
PyTorch	N/A	2.9.1+rocm7.2.0
Triton	N/A	3.5.1+rocm7.2.0
Kernel	6.14.0-37-generic	6.14.0-37-generic
Kernel Holds	In place	In place

Notes on gfx1151 Support

It's worth being explicit about the support situation. As of February 2026, gfx1151 (Strix Halo) is not listed on AMD's official ROCm support matrix. The supported RDNA 3 targets are gfx1100 (Navi 31, RX 7900 XTX) and gfx1101 (Navi 32). Strix Halo's gfx1151 is an RDNA 3.5 derivative that shares much of the ISA with gfx1100 but has architectural differences in the memory subsystem and compute unit layout.

In practice, ROCm 7.2 works on gfx1151. The kernel driver loads, rocminfo detects the GPU, and PyTorch can allocate tensors and dispatch compute kernels. The gfx11-generic ISA target in ROCm 7.2 is particularly helpful -- it provides a compatibility path for software that hasn't been explicitly compiled for gfx1151.

However, "works" and "fully supported" are different things. There are known quirks:

rocm-smi VRAM reporting: Always shows 0% on the APU since it only tracks discrete VRAM
No official PyTorch gfx1151 builds: The ROCm PyTorch wheels target gfx1100. They run on gfx1151 through ISA compatibility, but performance may not be optimal
Large model loading latency: Moving large models to the GPU device can be slow on the unified memory architecture, as the HSA runtime handles page migration differently than discrete GPU DMA transfers

If you're considering this hardware for production AI workloads, treat ROCm support as "functional but experimental." It works well enough for development, testing, and moderate inference workloads. For production training or latency-sensitive deployment, stick with hardware on AMD's official support list.

Rollback Plan

If the upgrade fails -- the DKMS module doesn't build, the GPU isn't detected after reboot, or something else goes wrong -- the rollback path is straightforward:

Uninstall ROCm 7.2:

sudo amdgpu-uninstall -y
sudo apt purge -y amdgpu-install

Reinstall ROCm 7.0.2:

wget https://repo.radeon.com/amdgpu-install/30.10.2/ubuntu/noble/amdgpu-install_30.10.2.0.30100200-2226257.24.04_all.deb
sudo apt install -y ./amdgpu-install_30.10.2.0.30100200-2226257.24.04_all.deb
sudo apt update
sudo amdgpu-install -y --usecase=graphics,rocm
sudo reboot

The entire rollback takes about 15 minutes. Keep the old amdgpu-install deb URL handy -- it's not linked from AMD's current download pages once a newer version is published.

Conclusion

Upgrading ROCm on hardware that isn't officially supported always carries some risk, but this upgrade from 7.0.2 to 7.2 on gfx1151 was uneventful. The procedure follows AMD's documented uninstall-reinstall approach with no deviations. The kernel hold strategy kept the kernel stable, the DKMS module built cleanly against 6.14.0-37-generic, and all post-reboot checks passed.

The improvements in ROCm 7.2 -- particularly the HSA runtime bump to 1.15 and the introduction of the gfx11-generic ISA target -- represent meaningful progress for Strix Halo users. The ecosystem is slowly catching up to the hardware. It's not there yet, but each release closes the gap.

For anyone running a Ryzen AI MAX+ 395 or similar Strix Halo hardware on Ubuntu 24.04, this upgrade is worth doing. The procedure is well-defined, the rollback path is clear, and the newer driver stack brings tangible benefits. Just remember to hold your kernel first.

Recommended Resources

Hardware

Bosgame M5 AI Mini PC (Ryzen AI MAX+ 395) - The system used in this post
GMKtec EVO X2 (Ryzen AI MAX+ 395) - Another Strix Halo mini PC option on Amazon

Books

Deep Learning with PyTorch by Stevens, Antiga, Huang, Viehmann - Comprehensive guide to building, training, and tuning neural networks with PyTorch
Programming PyTorch for Deep Learning by Ian Pointer - Practical guide to creating and deploying deep learning applications
Understanding Deep Learning by Simon Prince - Modern treatment of deep learning fundamentals