Some modules (coretemp, microcode) are not auto-loaded
elboulangero
Status: Curious
Joined: 26 Feb 2014
Posts: 5
Reply Quote
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
damentz
Status: Assistant
Joined: 09 Sep 2008
Posts: 1117
Reply Quote
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
elboulangero
Status: Curious
Joined: 26 Feb 2014
Posts: 5
Reply Quote
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.
:: Code ::

$ dpkg -l | grep microcode
ii  amd64-microcode                            2.20131007.1+really20130710.1   amd64        Processor microcode firmware for AMD CPUs
ii  intel-microcode                            2.20140122.1                    amd64        Processor microcode firmware for Intel CPUs
ii  iucode-tool                                1.0.1-1                         amd64        Intel processor microcode tool


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

$ uname -a
Linux crunchbang 3.13-5.dmz.2-liquorix-amd64 #1 ZEN SMP PREEMPT Tue Feb 25 07:04:45 UTC 2014 x86_64 GNU/Linux
$ dmesg | grep microcode
$ cat /proc/cpuinfo | grep microcode | uniq
microcode       : 0x12


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

$ uname -a
Linux crunchbang 3.10-12.dmz.1-liquorix-amd64 #1 ZEN SMP PREEMPT Sun Sep 15 17:29:51 UTC 2013 x86_64 GNU/Linux
$ dmesg | grep microcode
CPU0 microcode updated early to revision 0x19, date = 2013-06-13
CPU1 microcode updated early to revision 0x19, date = 2013-06-13
CPU2 microcode updated early to revision 0x19, date = 2013-06-13
CPU3 microcode updated early to revision 0x19, date = 2013-06-13
microcode: CPU0 sig=0x306a9, pf=0x10, revision=0x19
microcode: CPU1 sig=0x306a9, pf=0x10, revision=0x19
microcode: CPU2 sig=0x306a9, pf=0x10, revision=0x19
microcode: CPU3 sig=0x306a9, pf=0x10, revision=0x19
microcode: CPU4 sig=0x306a9, pf=0x10, revision=0x19
microcode: CPU5 sig=0x306a9, pf=0x10, revision=0x19
microcode: CPU6 sig=0x306a9, pf=0x10, revision=0x19
microcode: CPU7 sig=0x306a9, pf=0x10, revision=0x19
microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
$ cat /proc/cpuinfo | grep microcode | uniq
microcode       : 0x19


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

And here are the diff between the kernel configurations:
:: Code ::

$ grep MICROCODE /boot/config-3.13-5.dmz.2-liquorix-amd64
CONFIG_MICROCODE=m
CONFIG_MICROCODE_INTEL=y
CONFIG_MICROCODE_AMD=y
CONFIG_MICROCODE_OLD_INTERFACE=y
CONFIG_MICROCODE_INTEL_LIB=y
# CONFIG_MICROCODE_INTEL_EARLY is not set
# CONFIG_MICROCODE_AMD_EARLY is not set

$ grep MICROCODE /boot/config-3.10-12.dmz.1-liquorix-amd64
CONFIG_MICROCODE=m
CONFIG_MICROCODE_INTEL=y
CONFIG_MICROCODE_AMD=y
CONFIG_MICROCODE_OLD_INTERFACE=y
CONFIG_MICROCODE_INTEL_LIB=y
CONFIG_MICROCODE_INTEL_EARLY=y
CONFIG_MICROCODE_EARLY=y


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
elboulangero
Status: Curious
Joined: 26 Feb 2014
Posts: 5
Reply Quote
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:
:: Code ::

$ cat /sys/devices/system/cpu/modalias
x86cpu:vendor:0000:family:0006:model:003A:feature:,0000,0001,0002,0003,0004,0005,0006,0007,0008,0009,000B,000C,000D,000E,000F,0010,0011,0013,0015,0016,0017,0018,0019,001A,001B,001C,001D,001F,002B,0034,003B,003D,0068,006B,006C,006D,006F,0070,0072,0074,0075,0076,0078,007C,007D,0080,0081,0082,0083,0084,0085,0086,0087,0088,0089,008D,008E,008F,0091,0093,0094,0095,0097,0098,0099,009A,009B,009C,009D,009E,00C0,00E0,00E1,00E3,00E4,00E5,00E6,00E7,0100,0101,0102,0103,0104,0120,0127,0129


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

$ grep '^alias x86cpu' /lib/modules/3.13-5.dmz.2-liquorix-amd64/modules.alias | \
grep -e 'vendor:0000' -e 'vendor:\*' | \
grep -e 'family:0006' -e 'family:\*' | \
grep -e 'model:003A' -e 'model:\*'
alias x86cpu:vendor:0000:family:*:model:*:feature:* microcode
alias x86cpu:vendor:*:family:*:model:*:feature:*0099* aesni_intel
alias x86cpu:vendor:*:family:*:model:*:feature:*0081* ghash_clmulni_intel
alias x86cpu:vendor:*:family:*:model:*:feature:*0094* crc32c_intel
alias x86cpu:vendor:*:family:*:model:*:feature:*0081* crc32_pclmul
alias x86cpu:vendor:*:family:*:model:*:feature:*0081* crct10dif_pclmul
alias x86cpu:vendor:*:family:*:model:*:feature:*0085* kvm_intel
alias x86cpu:vendor:*:family:*:model:*:feature:*00C2* kvm_amd
alias x86cpu:vendor:*:family:*:model:*:feature:*00A2* via_rng
alias x86cpu:vendor:0000:family:*:model:*:feature:*00E7* coretemp
alias x86cpu:vendor:0000:family:0006:model:003A:feature:* intel_powerclamp
alias x86cpu:vendor:0000:family:*:model:*:feature:*00E6* x86_pkg_temp_thermal
alias x86cpu:vendor:*:family:*:model:*:feature:*00E9* amd_freq_sensitivity
alias x86cpu:vendor:*:family:*:model:*:feature:*00A6* padlock_aes
alias x86cpu:vendor:*:family:*:model:*:feature:*00AA* padlock_sha
alias x86cpu:vendor:0000:family:0006:model:003A:feature:* intel_rapl


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:
:: Code ::

$ grep CONFIG_ACPI_PROCESSOR= /boot/config-3.13-5.dmz.2-liquorix-amd64
CONFIG_ACPI_PROCESSOR=y
$ grep CONFIG_ACPI_PROCESSOR= /boot/config-3.13-1-amd64
CONFIG_ACPI_PROCESSOR=m


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
damentz
Status: Assistant
Joined: 09 Sep 2008
Posts: 1117
Reply Quote
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
elboulangero
Status: Curious
Joined: 26 Feb 2014
Posts: 5
Reply Quote
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
elboulangero
Status: Curious
Joined: 26 Feb 2014
Posts: 5
Reply Quote
Solved in 3.13-7.dmz.1, thanks !
Back to top
Display posts from previous:   

All times are GMT - 8 Hours