# [solved] misssing microcode update messages in dmesg

## toralf

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 :

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

```
# 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

----------

## bunder

wasn't 2018-01-18 rescinded?  i would try upgrading (or downgrading).

----------

## toralf

 *bunder wrote:*   

> wasn't 2018-01-18 rescinded?  i would try upgrading (or downgrading).

 I do have latest stable sys-firmware/intel-microcode-20180312

----------

## NeddySeagoon

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.

----------

## toralf

 *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.
> ...

 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 ?

----------

## krinn

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

----------

## NeddySeagoon

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.

----------

## krinn

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.

----------

## toralf

Well, I had 

```
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 

```
$ 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 

```
# 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  :Sad: 

----------

## NeddySeagoon

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.

----------

## toralf

 *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.
> ...

 Yep, I needed to add the iwlwifi firmware too:

```
$ 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.

----------

## Hu

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.

----------

## toralf

 *Hu wrote:*   

> My advice is go back to a modular kernel, but make all microcode related drivers and firmware built-in.

 IMO I tried that: https://paste.pound-python.org/show/nKbsfyuqeCqreALTpecu/ Or - and that .config didn't worked as expected

----------

