Stop your kernel module load order from wrecking your driver behavior

Technical Briefing | 7/31/2026

You spend all morning chasing a race condition in a custom storage driver, only to realize that the kernel decided to initialize a dependency in the wrong order. It is a classic head-scratcher. The kernel module loader does a decent job with symbol dependencies, but it doesn’t always account for hardware probe order or device node availability. I once spent six hours debugging an intermittent failure that only appeared on boot, eventually tracing it to a driver attempting to talk to an interface before its own provider module had finished its internal init routine.

Why static dependencies are not enough

The kernel uses modprobe and the modules.dep file to handle basic loading, but this only cares if symbols are resolved. It does not care if the driver needs a millisecond to register itself in the sysfs tree before the next module expects to see it. If your driver creates a character device, you might find that userspace udev rules trigger, fail, and stop before your device node actually exists. Most people just add a sleep command to an init script to fix this, but that is a hack that will bite you when your system load spikes.

cat /sys/module/your_driver_name/initstate

• Check your modules.alias file to see if the kernel actually recognizes the hardware trigger
• Inspect dmesg for late-loading warnings that point to circular dependencies
• Force your load order in /etc/modules-load.d/ rather than relying on dynamic udev events

The right approach is to be explicit about your requirements inside the module code using MODULE_SOFTDEP. By defining a soft dependency, you tell the kernel that your module might need another one present, even if there isn’t a direct symbol link. It saves you from that panicked realization that your driver is silently falling back to a degraded state just because a dependency initialized half a second late. Keep an eye on your modprobe output with the verbose flag enabled when you are testing these changes; it reveals the exact sequence the kernel takes.

Next time you are stuck fighting a driver that works when loaded manually but flakes out at boot, stop guessing. Query the module state in sysfs and look at your softdeps. It is cleaner than fighting the init system.