Chasing a NaN: correct RVV HPL on a RISC-V SpaceMiT X60, through EESSI

K1
1

A fresh-install, end-to-end walkthrough on an Orange Pi RV2: reproduce a silent NaN failure in the stock EESSI HPL, trace it to one RISC-V vector kernel, and fix it — correct results — with a single eb --from-pr.

TL;DR

  • The Orange Pi RV2 (SpaceMiT K1, eight X60 cores) is a vector RISC-V board: RVV 1.0, VLEN=256. Unlike the scalar SiFive U74, its OpenBLAS already has a mature RVV GEMM kernel (RISCV64_ZVL256B), and the stock EESSI OpenBLAS 0.3.30 is a DYNAMIC_ARCH build that does dispatch it on this chip.
  • So RVV is engaged out of the box — but the result is wrong: stock EESSI HPL fails with residual nan on the X60. The run even reports a healthy-looking ~8.5 GFLOP/s; only the residual check reveals the answer is garbage.
  • The cause is a one-kernel bug in OpenBLAS 0.3.30’s RVV gemv_n (it zeroes an uninitialized vector register). It was fixed upstream in v0.3.31 (OpenMathLib/OpenBLAS#5408). Backporting that single kernel restores correctness: HPL passes (residual ~4e-03).
  • The fix is packaged for EESSI as an EasyBuild easyconfig + patch (easybuilders/easybuild-easyconfigs#26444). This post reproduces the whole thing from a clean CVMFS stack: see the NaN, build the fix straight from the PR, swap it in with FlexiBLAS, and watch HPL pass — without recompiling HPL.

Everything below was run on a real Orange Pi RV2, entirely from the EESSI CVMFS stack.

https://www.eessi.io/docs/blog/2026/07/12/risc-v-x60-openblas-hpl/