View previous topic :: View next topic |
Author |
Message |
toralf Developer
Joined: 01 Feb 2004 Posts: 3922 Location: Hamburg
|
Posted: Sat Mar 17, 2018 8:58 am Post subject: [solved] misssing microcode update messages in dmesg |
|
|
I run the same kernel 4.15.10 at my server (i7) and at my ThinkPad (i5). The server tells me in dmesg, that the microcode is up to date : Code: | iucode_tool -S -l /lib/firmware/intel-ucode/* | tail -n 2
iucode_tool: system has processor(s) with signature 0x000206d7
045/001: sig 0x000206d6, pf_mask 0x6d, 2018-01-30, rev 0x061c, size 18432
046/001: sig 0x000206d7, pf_mask 0x6d, 2018-01-26, rev 0x0713, size 19456
# grep -e microcode -e 40651 /var/log/dmesg
[ 0.000000] microcode: microcode updated early to revision 0x713, date = 2018-01-26
[ 0.521829] microcode: sig=0x206d7, pf=0x4, revision=0x713
[ 0.522085] microcode: Microcode Update Driver: v2.2. | The notebook however lacks the dmesg message about the date : Code: | # iucode_tool -S -l /lib/firmware/intel-ucode/* | tail -n 2
iucode_tool: system has processor(s) with signature 0x00040651
selected microcodes:
056/001: sig 0x00040651, pf_mask 0x72, 2018-01-18, rev 0x0023, size 21504
# grep -e microcode -e 40651 /var/log/dmesg
[ 0.753779] microcode: sig=0x40651, pf=0x40, revision=0x20
[ 0.753874] microcode: Microcode Update Driver: v2.2. | I do wonder why (FWIW the notebook has modules whilst the kernel doesn't have kernel modules)
Last edited by toralf on Sat Mar 17, 2018 8:34 pm; edited 1 time in total |
|
Back to top |
|
|
bunder Bodhisattva
Joined: 10 Apr 2004 Posts: 5934
|
Posted: Sat Mar 17, 2018 10:18 am Post subject: |
|
|
wasn't 2018-01-18 rescinded? i would try upgrading (or downgrading). |
|
Back to top |
|
|
toralf Developer
Joined: 01 Feb 2004 Posts: 3922 Location: Hamburg
|
Posted: Sat Mar 17, 2018 10:22 am Post subject: |
|
|
bunder wrote: | wasn't 2018-01-18 rescinded? i would try upgrading (or downgrading). | I do have latest stable sys-firmware/intel-microcode-20180312 |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54237 Location: 56N 3W
|
Posted: Sat Mar 17, 2018 10:45 am Post subject: |
|
|
toralf,
I have a feeling that modules no longer work for Intel microcode updates.
The update has to be done very early in the boot process, so built in is required.
This is not based on experience as my only Intel CPU is an Atom N270. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
toralf Developer
Joined: 01 Feb 2004 Posts: 3922 Location: Hamburg
|
Posted: Sat Mar 17, 2018 11:14 am Post subject: |
|
|
NeddySeagoon wrote: | toralf,
I have a feeling that modules no longer work for Intel microcode updates.
The update has to be done very early in the boot process, so built in is required.
This is not based on experience as my only Intel CPU is an Atom N270. | That was it!.
Now I do just need how to activate my WLAN interface - I simply deactivated the modules in the kernel config and now the wlan device is not shown after boot.
Hhm ? |
|
Back to top |
|
|
krinn Watchman
Joined: 02 May 2003 Posts: 7470
|
Posted: Sat Mar 17, 2018 11:52 am Post subject: |
|
|
You guys makes it unclear.
As for me you speak like module should be off.
Just to make it clearer : keep using module support, but for microcode update you cannot load it "later" to update the cpu microcode ; it must be done early, so module support is need to handle the module and the module need to be set in CONFIG_EXTRA_FIRMWARE for early update.
And i suppose your "I simply deactivated the modules" mean "i have switch my WLAN from module to build-in"?
Because obviously if you had only deactivate the module, your WLAN has no longer any drivers to work with and anyone could explains the mystery why it is no longer shown after boot |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54237 Location: 56N 3W
|
Posted: Sat Mar 17, 2018 12:00 pm Post subject: |
|
|
Module support can be used for other things.
For Intel firmware updates, the option must be selected as built into the kernel and the required firmware must be included in the kernel too.
There is no need to change anything wifi related. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
krinn Watchman
Joined: 02 May 2003 Posts: 7470
|
Posted: Sat Mar 17, 2018 2:41 pm Post subject: |
|
|
Yeah must be my understanding of English but also could be it's a few too subtle for common non native users.
Anyway, i was thinking it should be a few clearer what the "disable" really mean in that case for non native like me, where the "disable" is not really disabling anything. |
|
Back to top |
|
|
toralf Developer
Joined: 01 Feb 2004 Posts: 3922 Location: Hamburg
|
Posted: Sat Mar 17, 2018 3:33 pm Post subject: |
|
|
Well, I had Code: | t44 ~ # zgrep FIRMW /usr/src/linux/.config
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FIRMWARE_IN_KERNEL=y
CONFIG_EXTRA_FIRMWARE="intel-ucode/06-45-01"
CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware"
| for a modularized kernel, but that gives just Code: | $ grep . /sys/devices/system/cpu/vulnerabilities/*
/sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI
/sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: __user pointer sanitization
/sys/devices/system/cpu/vulnerabilities/spectre_v2:Vulnerable: Minimal generic ASM retpoline
| whereas with the new microcode I do get Code: | # grep . /sys/devices/system/cpu/vulnerabilities/*
/sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI
/sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: __user pointer sanitization
/sys/devices/system/cpu/vulnerabilities/spectre_v2:Vulnerable: Minimal generic ASM retpoline, IBPB, IBRS_FW
|
But till now I didn't get WLAN up and running with a monolithic kernel |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54237 Location: 56N 3W
|
Posted: Sat Mar 17, 2018 5:27 pm Post subject: |
|
|
toralf,
There is no need to make a monolthic kernel.
You need to build in your wifi module and firmware if you want to do that.
Going forward, you need to make sure that new firmware is installed before you build your kernel. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
toralf Developer
Joined: 01 Feb 2004 Posts: 3922 Location: Hamburg
|
Posted: Sat Mar 17, 2018 5:54 pm Post subject: |
|
|
NeddySeagoon wrote: | toralf,
There is no need to make a monolthic kernel.
You need to build in your wifi module and firmware if you want to do that.
Going forward, you need to make sure that new firmware is installed before you build your kernel. | Yep, I needed to add the iwlwifi firmware too: Code: | $ zgrep FIRM /proc/config.gz
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FIRMWARE_IN_KERNEL=y
CONFIG_EXTRA_FIRMWARE="intel-ucode/06-45-01 iwlwifi-7260-17.ucode"
CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware"
| But if I do build modularized kernel, then I didn't get ", IBPB, IBRS_FW ". But for a monolithic kernel I do have that. |
|
Back to top |
|
|
Hu Moderator
Joined: 06 Mar 2007 Posts: 21633
|
Posted: Sat Mar 17, 2018 9:17 pm Post subject: |
|
|
It's possible that there is a kernel limitation here, but it looks to me more like a communication problem. According to the earlier posts, the microcode update must be built-in. If it is not, it initializes too late to be possible, so it is skipped and you do not get the full mitigations. You attempted to make the entire kernel monolithic, which works, but is overkill for that problem. More importantly, while wireless can be made to work in a monolithic kernel, it is more trouble, at least for some cards.
My advice is go back to a modular kernel, but make all microcode related drivers and firmware built-in. |
|
Back to top |
|
|
toralf Developer
Joined: 01 Feb 2004 Posts: 3922 Location: Hamburg
|
|
Back to top |
|
|
|