Upgrading a Linux subsystem often feels like a balancing act between software modernization and hardware longevity. Recently, I hit a roadblock while preparing to update a system with a HighPoint RocketRAID 640L RAID controller to a modern Linux 6.18.x kernel.
The vendor’s out-of-tree open-source driver wrapper, which compiles flawlessly on older kernels going back at least as far as Linux-3.10.x and up through recent 5.15.x and 6.12.x trees, abruptly threw a wall of fatal compilation errors and ground the kernel upgrade to a halt. I was able to update instead to a then-newer version of Linux-6.12.x, knowing that I would eventually need to bite the bullet and solve the compilation problem, or else just stop using the RAID controller (which has worked very well for me for many years, I must add).
If you are trying to keep your legacy HighPoint arrays alive on modern Linux deployments, here is a breakdown of what broke behind the scenes resulting in the driver no longer building correctly, how to fix it, and where to grab the resulting patch.
The Roadblocks: What Changed in Kbuild and the Linux Kernel?
Modernizing out-of-tree drivers requires chasing a moving target. In this case, three distinct areas of Linux kernel refactoring conspired to break the vendor’s source code.
1. The Death of EXTRA_CFLAGS
The first failure was an immediate header compilation error:
fatal error: osm_linux.h: No such file or directory.
Even though the local directory structure was perfectly valid, the modern Kbuild subsystem was completely ignoring the Makefile’s legacy EXTRA_CFLAGS variable. Because Kbuild sandboxes out-of-tree module compilation inside the main kernel source tree directory, the relative include paths (-I) provided by EXTRA_CFLAGS were dropped.
The Fix: Migrating the build configuration in Makefile.def to use the modern, standard ccflags-y variable forces Kbuild to pass absolute directory paths to GCC.
2. The Great Timer API Refactoring (Linux 6.15 / 6.16)
Once GCC could actually find the driver headers, the compiler failed on several standard kernel timer functions in os_linux.c and osm_linux.c.
Between Linux 6.15 and 6.16, the kernel developers finalized (finalized?) a massive, multi-year cleanup of the Kernel Timer API to harden type safety and remove obsolete macros:
from_timer() was entirely deleted and replaced bytimer_container_of().
del_timer() and del_timer_sync() were dropped in favor of
the unified, prefixed timer_delete() and timer_delete_sync()
functions.
destroy_timer_on_stack() was cleanly renamed to timer_destroy_on_stack().
The Fix: Find and replace the affected function calls.
3. Block Layer Macro Unification
Finally, the block layer subsystem cleaned up historical, ambiguous device limit macros. The old maximum capability definition BLK_DEF_MAX_SECTORS_CAP was completely phased out of the kernel source tree, breaking the driver’s fallback calculations.
The Fix: Swapping this out for the standard, type-safe fallback BLK_SAFE_MAX_SECTORS allowed the driver’s block queue configuration routines to compile cleanly.
Bypassing Vendor Silos with a Clean Patch
Because this driver relies on proprietary, pre-compiled binary objects distributed directly by HighPoint, redistributing a completely modified source archive can venture into muddy licensing waters. I respect their choice to keep their device driver closed, while still making it avilable to Linux users, but I also want to help folks who use this device continue to do so even on modern Linux kernels.
To help the Linux sysadmin community bypass these hurdles safely, I have generated a simple, unified multi-file .patch file. This patch targets only the open-source wrapper layer of the distributed driver (os_linux.c, osm_linux.c, and Makefile.def), keeping it entirely legal, open, and lightweight.
You can grab the patch file, read the deployment notes, and see the step-by-step instructions on my GitHub HighPoint-RR640L-Linux-Driver-Update repository.
Keeping older, highly capable RAID hardware out of landfills and keeping it securely supported on modern, stable Linux kernels is exactly why the open-source ecosystem shines. If you are running these controllers, extract the installer binaries, apply the patch, and compile to keep your data moving on modern Linux systems!