Change load order of a certain kernel module

Hi. I have a watercooler (NZXT Kraken), module is loaded (nzxt_kraken3). On Wayland KDE Plasma 6.6.0, showing liquid temperature of the watercooler in a KDE Widget (System Monitor Sensor).

I notice that 50% of the times I boot my PC, the temperature is not shown. Solving by manually adding the temperature again in the widget. All other sensor values are always 100% shown (cpu/gpu load, cpu/gpu temp, network up/down bps).

I suspect the ‘no show’ of this temperature is caused by the kernel module just not loaded yet. Hence my try put to load this module nzxt_kraken3 as soon as possible, by manually adjusting the load order of kernels.

Can this be done, changing the load order of kernel modules (I understand dependencies are involved). How?

Or, maybe even better, why is the liquid temp not always shown after booting up?

I somehow doubt that a race condition ( that is what you describe ) is going on. The kernel module is loaded during the actual boot to graphical.target , the widget is only loaded after Plasma started. With that in mind, it is worth checking the journal whether the module loads properly.
Please show:
sudo lsmod | grep nzxt
from both when the widget does work as expected, and when it doesn’t

Succes ermee :smile:

Hi. Sorry for the weeks of delay, have been busy working abroad. Your response is appreciated!

Will take a close look at it.

As of now, working situation:

sudo lsmod | grep nzxt
nzxt_kraken3           36864  0

Although I believe the module is always loaded correctly, as CoolerControl is also using this mod (to instruct AIO pump and fans) and no issues/bad loggings with that app. But… let’s see what lsmod gives when coolant temp is not showing up in the KDE widget.

Dank je wel :wink:

1 Like

So, a couple of random reboots further this morning, sensor data from my AIO is not shown anymore.

Working situation:

sudo lsmod | grep nzxt
nzxt_kraken3           36864  0

After some reboots, yellow data becomes missing.

I can add the sensor data again, without problems. CoolerControl is also working in good order. Module is loaded. It looks like a problem with the widget, not always picking up that data…? If that’s the case, not aTW issue I guess → KDE bug report?


Module is also loaded.

sudo lsmod | grep nzxt
nzxt_kraken3           36864  0

Did you already try with a fresh user profile?

I could try that, a fresh user profile. But first, in my defence, I did a completely fresh install (including partitioning) yesterday morning (Sunday). Not 100% proof of my statement, but

rpm -qa --last | tail -1
gpg-pubkey-09d9ea69-68595a8c                  zo 22 mrt 2026 09:31:06 CET
ls -lact --full-time /etc |awk 'END {print $6,$7,$8}'
2026-03-22 09:31:09.920763689 +0100

So, yeah. I can try of course a new fresh profile, will do that. But doubt if that helps. But will do.

See here for the Kernel driver nzxt-kraken3:

https://docs.kernel.org/hwmon/nzxt-kraken3.html

When you see the widget showing incorrect you can also check the sysfs entries, this way you could determine if it is a driver or widget issue.

Hi Marel,

I am not sure if I understand you correctly, what you mean or what I should check.

In all cases (100%, no exception), the module nzxt3 is loaded correctly. Always. I can check that, for example, in CoolerControl, where sensor data of my AIO is correct. lsmod always shows the module is loaded. Also, when the ‘nzxt3-data’ is not shown in the KDE widget, I can manually add those data without any problem and all is well again. This shows me too the mod is loaded okay, even when the nzxt3-data is not shown in the widget from the beginning.

What exactly should I see with this list; is there a special thing I should take a closer look at?

cd /sys/module 
ls -las nzxt_kraken3/

0 drwxr-xr-x   6 root root    0 mrt 23 22:33 .
0 drwxr-xr-x 281 root root    0 mrt 23 22:33 ..
0 -r--r--r--   1 root root 4096 mrt 23 21:50 coresize
0 drwxr-xr-x   2 root root    0 mrt 23 21:50 drivers
0 drwxr-xr-x   2 root root    0 mrt 23 17:55 holders
0 -r--r--r--   1 root root 4096 mrt 23 21:50 initsize
0 -r--r--r--   1 root root 4096 mrt 23 21:50 initstate
0 drwxr-xr-x   2 root root    0 mrt 23 21:50 notes
0 -r--r--r--   1 root root 4096 mrt 23 21:50 refcnt
0 drwxr-xr-x   2 root root    0 mrt 23 21:50 sections
0 -r--r--r--   1 root root 4096 mrt 23 21:50 srcversion
0 -r--r--r--   1 root root 4096 mrt 23 21:50 taint
0 --w-------   1 root root 4096 mrt 23 16:54 uevent

You should be able to find the location of the SysFS entries using:

grep -l "nzxt" /sys/class/hwmon/hwmon*/name

That should give something like /sys/class/hwmon/hwmon3/name, do a cat to verify the name is exactly nzxt-kraken3 is.

After that a ls /sys/class/hwmon/hwmon3/ should show you the SysFS entries.

Ahhh, now I understand. Thank you!

It is in hwmon4, but not nzxt. It is ‘kraken2023’.

grep -l "kraken2023" /sys/class/hwmon/hwmon4/name
/sys/class/hwmon/hwmon4/name

Do I understand that although the driver is loaded correctly, when there’s no AIO-data in the widget I should check this output with a closer look to see if some .pwm data is missing. Right?

And here’s the other output.

ls /sys/class/hwmon/hwmon4/
device                  temp1_auto_point14_pwm  temp1_auto_point29_pwm  temp1_auto_point6_pwm   temp2_auto_point1_pwm   temp2_auto_point34_pwm
fan1_input              temp1_auto_point15_pwm  temp1_auto_point2_pwm   temp1_auto_point7_pwm   temp2_auto_point20_pwm  temp2_auto_point35_pwm
fan1_label              temp1_auto_point16_pwm  temp1_auto_point30_pwm  temp1_auto_point8_pwm   temp2_auto_point21_pwm  temp2_auto_point36_pwm
fan2_input              temp1_auto_point17_pwm  temp1_auto_point31_pwm  temp1_auto_point9_pwm   temp2_auto_point22_pwm  temp2_auto_point37_pwm
fan2_label              temp1_auto_point18_pwm  temp1_auto_point32_pwm  temp1_input             temp2_auto_point23_pwm  temp2_auto_point38_pwm
name                    temp1_auto_point19_pwm  temp1_auto_point33_pwm  temp1_label             temp2_auto_point24_pwm  temp2_auto_point39_pwm
power                   temp1_auto_point1_pwm   temp1_auto_point34_pwm  temp2_auto_point10_pwm  temp2_auto_point25_pwm  temp2_auto_point3_pwm
pwm1                    temp1_auto_point20_pwm  temp1_auto_point35_pwm  temp2_auto_point11_pwm  temp2_auto_point26_pwm  temp2_auto_point40_pwm
pwm1_enable             temp1_auto_point21_pwm  temp1_auto_point36_pwm  temp2_auto_point12_pwm  temp2_auto_point27_pwm  temp2_auto_point4_pwm
pwm2                    temp1_auto_point22_pwm  temp1_auto_point37_pwm  temp2_auto_point13_pwm  temp2_auto_point28_pwm  temp2_auto_point5_pwm
pwm2_enable             temp1_auto_point23_pwm  temp1_auto_point38_pwm  temp2_auto_point14_pwm  temp2_auto_point29_pwm  temp2_auto_point6_pwm
subsystem               temp1_auto_point24_pwm  temp1_auto_point39_pwm  temp2_auto_point15_pwm  temp2_auto_point2_pwm   temp2_auto_point7_pwm
temp1_auto_point10_pwm  temp1_auto_point25_pwm  temp1_auto_point3_pwm   temp2_auto_point16_pwm  temp2_auto_point30_pwm  temp2_auto_point8_pwm
temp1_auto_point11_pwm  temp1_auto_point26_pwm  temp1_auto_point40_pwm  temp2_auto_point17_pwm  temp2_auto_point31_pwm  temp2_auto_point9_pwm
temp1_auto_point12_pwm  temp1_auto_point27_pwm  temp1_auto_point4_pwm   temp2_auto_point18_pwm  temp2_auto_point32_pwm  uevent
temp1_auto_point13_pwm  temp1_auto_point28_pwm  temp1_auto_point5_pwm   temp2_auto_point19_pwm  temp2_auto_point33_pwm

Also a point of interest when looking at the log of CoolerControl: I see hwmon4, which we discovered earlier. But, also a skipping device on exactly kraken2023 due to duplicate in liquidctl. Interesting, maybe this is the issue, how the coin flips on this duplicate thing, to show or not show the AIO data in the widget. Will take a closer look.

[2026-03-23T15:54:33Z INFO  coolercontrold::repositories::liquidctl::liquidctl_repo] Initialized Liquidctl Devices: {"NZXT Kraken 2023":{"locations":["/dev/hidraw13","/sys/class/hidraw/hidraw13/device/hwmon/hwmon4"],"driver version":["1.16.0"],"driver name":["KrakenZ3"]}}
[2026-03-23T15:54:34Z INFO  coolercontrold::repositories::hwmon::hwmon_repo] Skipping HWMon detected device: kraken2023 due to an existing duplicate liquidctl device

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.