Hi,

I've noticed that the coretemp module is not auto-loaded as it used to be.

By digging the net a little bit, I found this thread:
https://lkml.org/lkml/2013/9/30/615

It made me notice that microcode was missing too, and maybe other modules that I don't even know about.

However, this thread describes a udev problem, and the broken udev rule has been fixed upstream. I checked that the udev script mentioned is correct on my system. Furthermore, if I boot the latest Debian kernel (3.13-1-amd64), coretemp and microcode are automatically loaded.

That's why I believe it's related to Liquorix.
The latest Liquorix version where these modules were auto-loaded is 3.10-12.dmz.1-liquorix-amd64 (which I still use today).
From then, I tried newer Liquorix versions from time to time (up to 3.13-5.dmz.1-liquorix-amd64), and the problem is still there.

I don't really know what I can do to investigate this problem further, any idea would be appreciated.

Thanks !
Back to top

I think microcode and coretemp are not loaded by default for a good reason.

1) 'microcode' is normally used during boot as part of the microcode patching process. IMHO there's no reason to have this module loaded unless you're going to use it immediately.

2) 'coretemp' is used by lm-sensors. I don't know if this is true, but it's probably dangerous to simply load this module up regardless of which machine its on. Lm-sensors itself warns that during scanning it can for sensors can cause hangs itself. Once it successfully scans, then it gives you the option of inserting 'coretemp' into /etc/modules. This is fair too.

Sure, I can build these statically in the kernel, but what's the point of there's specific userspace tools that do that for you? For microcode, install the right microcode packages (intel-microcode / amd64-microcode). For coretemp, run sensors-detect and add coretemp to your modprobe config if the scan runs successfully.
Back to top

Hi damantz, thanks for your reply.

I've been very interested in this subject and I spend my whole day looking at that !
Actually, it's not really that it bothers me, but I feel a bit curious.
OK, so I can now give a more accurate report of the situation.

About microcode

The microcode package is properly installed, no problem with that.


But despite that, the microcode is not patched. Have a look at some logs from the current liquorix:


If I boot an older version of Liquorix (or the current Debian kernel, it's the same):


As you can see, in the current Liquorix kernel, the microcode is not patched.

And here are the diff between the kernel configurations:


We can see that the EARLY have been disabled.

What I did, I grabbed the Liquorix source, enabled MICROCODE_EARLY, compiled and booted. And it did the trick.

I had a look on the net and found that there was a change in the kernel 3.11. The EARLY setting now depends on CONFIG_MICROCODE builtin only.
Here are some links about that:
lists.opensuse.org/opensuse-kernel/2013-07/msg00033.html
www.spinics.net/lists/linux-tip-commits/msg19736.html

So, I'm wondering if the change here was made on purpose, or if it slipped in as a mistake. What do you think ?

< Edited by elboulangero :: Mar 8, 14, 16:17 >
Back to top

About coretemp

About coretemp, I was still a bit puzzled. Sure I could add it to my modprobe config, but why was it automatically loaded in Liquorix before ? And why is it automatically loaded in the current Debian Kernel ?

I don't know much on that subject, but from what I learned, it seems that coretemp implements a feature of the CPU, and should be automatically loaded if the CPU has this feature, thanks to the modalias mechanism and udev.

I can get a few info about my CPU like that:


The more interesting stuff are the vendor, family and model.
Let's see which modules should be loaded for this CPU:


We can see that coretemp is in the list, amongst many other modules. What's interesting is that none of them are loaded in the current Liquorix version ! Of course, I checked in the kernel conf that they are not configured as builtin.
I compared with the current Debian kernel, and almost all these modules are loaded.

With my thin understanding, I would think that the auto-load mechanism of the modules that are CPU-related is broken.

After that, basically I played with the kernel configuration, compared it with the Debian kernel conf. I found that a single parameter that do the trick:


Simply by setting ACPI_PROCESSOR as a module instead of builtin, and recompiling the kernel, all the modules are properly auto-loaded.
To be honest, it's black magic to me. I hope it makes sense for you.
Do you think I spot a bug, or am I just wasting your time ;) ?
Back to top

In 3.13-6.dmz.1, I set ACPI_PROCESSOR and a few other acpi modules as static. I left coretemp as a module though, let me know if this change worked for you.
Back to top

Hi Damentz, thanks for your concern !
Unfortunately, the CPU-related modules (including coretemp) are not auto-loaded.
Maybe it was not clear enough in my previous post, so I say it again just to avoid misunderstandings: on my laptop, ACPI_PROCESSOR must be set as a module in order to trigger the auto-load of other CPU-related modules. Not builtin.
Back to top

Solved in 3.13-7.dmz.1, thanks !
Back to top