Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
[SOLVED] microcode-data-20150121-r1 with USE=initramfs:panic
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware
View previous topic :: View next topic  
Author Message
bszente
Tux's lil' helper
Tux's lil' helper


Joined: 14 Feb 2005
Posts: 123
Location: Tirgu Mures, Romania

PostPosted: Tue Aug 25, 2015 8:27 pm    Post subject: [SOLVED] microcode-data-20150121-r1 with USE=initramfs:panic Reply with quote

Hi folks!

I'm writing here my problem, in hope that somebody will shed a light on my issue... It has been years since my last forum post...

Very brief description of the system:
  • Lenovo G510 with Core i7-4702MQ
  • EFI v2.31 by INSYDE Corp.
  • sys-kernel/gentoo-sources-4.1.6 on x86_64 booted directly with EFI stub loader, without any initramfs or GRUB, just plain kernel image
Everything was fine, system worked without any issues until the recent microcode-ctl and microcode-data package updates. Description of problem:
  1. Upgrading to sys-apps/microcode-ctl-1.28-r1 the init scripts vanished
  2. I carefully read the microcode-ctl-1.28-r1.ebuild
  3. Followed exactly the steps described in the related Gentoo bug #528712#c41 comment
Result: kernel panic with unable to mount rootfs

Based on the detailed description in Gentoo bug #528712#c55 comment I realised it is the same situation as mine. And indeed, after including those missing 3 files in the microcode.cpio file, the kernel boots properly.

I issued a new Gentoo bug #558192 for this (from my point of view) incomplete microcode.cpio file, but according to the maintainer i'm clearly doing it wrong and the issue is with my system with no further explanation. So finally I took his advice, and I'm seeking help now here at Gentoo Forums, because I want to understand what is happening.

So my questions:
  1. Is there anybody who managed to boot a stand-alone kernel with CONFIG_INITRAMFS_SOURCE set to /lib/firmware/microcode.cpio, as it is advised, but WITHOUT any external initramfs?
  2. Do you have any hint/idea, what did I do wrong that in my (and other users as well) case does not work? However the kernel ramfs, rootfs and initramfs documentation clearly states that the initramfs must be populated and must have a certain format, thus it makes sense that by embedding microcode.cpio the kernel does not boot. On the other hand the maintainer states it works for him (without any further details/explanation) which apparently means i'm doing it wrong. But what am I doing wrong? :)
Thank you.

Note: the panic happens as well with legacy BIOS machines using GRUB. So the BIOS or boot loader does not matter. The only thing I found that matters is the content of the embedded cpio archive.


Last edited by bszente on Wed Sep 16, 2015 7:14 pm; edited 1 time in total
Back to top
View user's profile Send private message
Fitzcarraldo
Veteran
Veteran


Joined: 30 Aug 2008
Posts: 1773
Location: United Kingdom

PostPosted: Wed Aug 26, 2015 5:44 pm    Post subject: Reply with quote

In the Gentoo amd64 installation on my Clevo W230SS laptop I don't use an initramfs either.

In this case should the path specified in CONFIG_INITRAMFS_SOURCE be relative or absolute? In other words, should it be specified as CONFIG_INITRAMFS_SOURCE="/lib/firmware/microcode.cpio" as SpanKY wrote in Comment #41 of Bug Report #528712, or should it be specified as CONFIG_INITRAMFS_SOURCE="/microcode.cpio"? The reason I ask is because early microcode updating works for me if I leave CONFIG_INITRAMFS_SOURCE="", copy the microcode cpio file to /boot/ and add the line 'initrd /microcode.cpio' to grub.cfg as explained in detail below.

Before doing anything at all, I checked the microcode version for my CPU (Intel Core i7-4810MQ @ 2.80GHz):

Code:
# grep microcode /proc/cpuinfo
microcode   : 0x12
microcode   : 0x12
microcode   : 0x12
microcode   : 0x12
microcode   : 0x12
microcode   : 0x12
microcode   : 0x12
microcode   : 0x12
# dmesg | grep microcode
[    0.262544] microcode: CPU0 sig=0x306c3, pf=0x10, revision=0x12
[    0.262641] microcode: CPU1 sig=0x306c3, pf=0x10, revision=0x12
[    0.262740] microcode: CPU2 sig=0x306c3, pf=0x10, revision=0x12
[    0.262841] microcode: CPU3 sig=0x306c3, pf=0x10, revision=0x12
[    0.262939] microcode: CPU4 sig=0x306c3, pf=0x10, revision=0x12
[    0.263038] microcode: CPU5 sig=0x306c3, pf=0x10, revision=0x12
[    0.263138] microcode: CPU6 sig=0x306c3, pf=0x10, revision=0x12
[    0.263236] microcode: CPU7 sig=0x306c3, pf=0x10, revision=0x12
[    0.263367] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba


Fortunately I did not need to rebuild the kernel as I had already configured it back in April with a view to implementing early microcode updating:

Code:
# grep CONFIG_BLK_DEV_INITRD /usr/src/linux/.config
CONFIG_BLK_DEV_INITRD=y
# grep CONFIG_MICROCODE /usr/src/linux/.config
CONFIG_MICROCODE=y
CONFIG_MICROCODE_INTEL=y
# CONFIG_MICROCODE_AMD is not set
CONFIG_MICROCODE_OLD_INTERFACE=y
CONFIG_MICROCODE_INTEL_EARLY=y
# CONFIG_MICROCODE_AMD_EARLY is not set
CONFIG_MICROCODE_EARLY=y
# grep CONFIG_INITRAMFS_SOURCE /usr/src/linux/.config
CONFIG_INITRAMFS_SOURCE=""


Then I set the initramfs USE flag and unmasked the ~amd64 ebuilds created by SpanKY (microcode-ctl-1.28-r1.ebuild, microcode-data-20150121-r1.ebuild and iucode_tool-1.3.ebuild):

Code:
# cat /etc/portage/package.use/microcode-data
sys-apps/microcode-data initramfs
# cat /etc/portage/package.accept_keywords/microcode-data
sys-apps/microcode-data ~amd64
sys-apps/iucode_tool ~amd64
# cat /etc/portage/package.accept_keywords/microcode-ctl
sys-apps/microcode-ctl ~amd64


Then I merged the packages:

Code:
# emerge --ask microcode-ctl microcode-data


This resulted in the following files:

Code:
# ls -la /lib/firmware/microcode.cpio
-rw-r--r-- 1 root root 663552 Aug 26 15:06 /lib/firmware/microcode.cpio

Code:
# ls -la /lib/firmware/intel-ucode
total 768
drwxr-xr-x  2 root root  4096 Aug 26 15:06 .
drwxr-xr-x 62 root root 16384 Aug 26 15:06 ..
-rw-r--r--  1 root root  2048 Aug 26 15:06 06-03-02
-rw-r--r--  1 root root  6144 Aug 26 15:06 06-05-00
-rw-r--r--  1 root root  2048 Aug 26 15:06 06-05-01
-rw-r--r--  1 root root  6144 Aug 26 15:06 06-05-02
-rw-r--r--  1 root root  8192 Aug 26 15:06 06-05-03
-rw-r--r--  1 root root  2048 Aug 26 15:06 06-06-00
-rw-r--r--  1 root root  2048 Aug 26 15:06 06-06-05
-rw-r--r--  1 root root  6144 Aug 26 15:06 06-06-0a
-rw-r--r--  1 root root  6144 Aug 26 15:06 06-06-0d
-rw-r--r--  1 root root  2048 Aug 26 15:06 06-07-01
-rw-r--r--  1 root root  2048 Aug 26 15:06 06-07-02
-rw-r--r--  1 root root  2048 Aug 26 15:06 06-07-03
-rw-r--r--  1 root root 10240 Aug 26 15:06 06-08-01
-rw-r--r--  1 root root  4096 Aug 26 15:06 06-08-03
-rw-r--r--  1 root root 10240 Aug 26 15:06 06-08-06
-rw-r--r--  1 root root  6144 Aug 26 15:06 06-08-0a
-rw-r--r--  1 root root  6144 Aug 26 15:06 06-09-05
-rw-r--r--  1 root root  2048 Aug 26 15:06 06-0a-00
-rw-r--r--  1 root root  2048 Aug 26 15:06 06-0a-01
-rw-r--r--  1 root root  4096 Aug 26 15:06 06-0b-01
-rw-r--r--  1 root root  4096 Aug 26 15:06 06-0b-04
-rw-r--r--  1 root root  2048 Aug 26 15:06 06-0d-06
-rw-r--r--  1 root root  4096 Aug 26 15:06 06-0e-08
-rw-r--r--  1 root root  8192 Aug 26 15:06 06-0e-0c
-rw-r--r--  1 root root  8192 Aug 26 15:06 06-0f-02
-rw-r--r--  1 root root 12288 Aug 26 15:06 06-0f-06
-rw-r--r--  1 root root  8192 Aug 26 15:06 06-0f-07
-rw-r--r--  1 root root  4096 Aug 26 15:06 06-0f-0a
-rw-r--r--  1 root root 28672 Aug 26 15:06 06-0f-0b
-rw-r--r--  1 root root 12288 Aug 26 15:06 06-0f-0d
-rw-r--r--  1 root root 12288 Aug 26 15:06 06-16-01
-rw-r--r--  1 root root 20480 Aug 26 15:06 06-17-06
-rw-r--r--  1 root root  4096 Aug 26 15:06 06-17-07
-rw-r--r--  1 root root 24576 Aug 26 15:06 06-17-0a
-rw-r--r--  1 root root 14336 Aug 26 15:06 06-1a-04
-rw-r--r--  1 root root 10240 Aug 26 15:06 06-1a-05
-rw-r--r--  1 root root 15360 Aug 26 15:06 06-1c-02
-rw-r--r--  1 root root 20480 Aug 26 15:06 06-1c-0a
-rw-r--r--  1 root root  4096 Aug 26 15:06 06-1d-01
-rw-r--r--  1 root root  6144 Aug 26 15:06 06-1e-04
-rw-r--r--  1 root root  7168 Aug 26 15:06 06-1e-05
-rw-r--r--  1 root root  8192 Aug 26 15:06 06-25-02
-rw-r--r--  1 root root  3072 Aug 26 15:06 06-25-05
-rw-r--r--  1 root root 10240 Aug 26 15:06 06-26-01
-rw-r--r--  1 root root 10240 Aug 26 15:06 06-2a-07
-rw-r--r--  1 root root 16384 Aug 26 15:06 06-2d-06
-rw-r--r--  1 root root 17408 Aug 26 15:06 06-2d-07
-rw-r--r--  1 root root 13312 Aug 26 15:06 06-2f-02
-rw-r--r--  1 root root 12288 Aug 26 15:06 06-3a-09
-rw-r--r--  1 root root 21504 Aug 26 15:06 06-3c-03
-rw-r--r--  1 root root 14336 Aug 26 15:06 06-3d-04
-rw-r--r--  1 root root 13312 Aug 26 15:06 06-3e-04
-rw-r--r--  1 root root 11264 Aug 26 15:06 06-3e-06
-rw-r--r--  1 root root 15360 Aug 26 15:06 06-3e-07
-rw-r--r--  1 root root 28672 Aug 26 15:06 06-3f-02
-rw-r--r--  1 root root 20480 Aug 26 15:06 06-45-01
-rw-r--r--  1 root root 23552 Aug 26 15:06 06-46-01
-rw-r--r--  1 root root  4096 Aug 26 15:06 0f-00-07
-rw-r--r--  1 root root  6144 Aug 26 15:06 0f-00-0a
-rw-r--r--  1 root root  2048 Aug 26 15:06 0f-01-02
-rw-r--r--  1 root root  6144 Aug 26 15:06 0f-02-04
-rw-r--r--  1 root root  8192 Aug 26 15:06 0f-02-05
-rw-r--r--  1 root root  2048 Aug 26 15:06 0f-02-06
-rw-r--r--  1 root root  6144 Aug 26 15:06 0f-02-07
-rw-r--r--  1 root root  6144 Aug 26 15:06 0f-02-09
-rw-r--r--  1 root root  2048 Aug 26 15:06 0f-03-02
-rw-r--r--  1 root root  2048 Aug 26 15:06 0f-03-03
-rw-r--r--  1 root root  7168 Aug 26 15:06 0f-03-04
-rw-r--r--  1 root root 10240 Aug 26 15:06 0f-04-01
-rw-r--r--  1 root root  2048 Aug 26 15:06 0f-04-03
-rw-r--r--  1 root root  3072 Aug 26 15:06 0f-04-04
-rw-r--r--  1 root root  3072 Aug 26 15:06 0f-04-07
-rw-r--r--  1 root root  9216 Aug 26 15:06 0f-04-08
-rw-r--r--  1 root root  2048 Aug 26 15:06 0f-04-09
-rw-r--r--  1 root root  4096 Aug 26 15:06 0f-04-0a
-rw-r--r--  1 root root  3072 Aug 26 15:06 0f-06-02
-rw-r--r--  1 root root  6144 Aug 26 15:06 0f-06-04
-rw-r--r--  1 root root  2048 Aug 26 15:06 0f-06-05
-rw-r--r--  1 root root  2048 Aug 26 15:06 0f-06-08

(By the way, the file 06-3c-03 is the microcode file for my particular CPU: Family 06h, Model 03Ch, Stepping 03h, as determined from the CPU World Web site.)

Then I copied to the boot directory the cpio file created when I merged the packages:

Code:
# cp /lib/firmware/microcode.cpio /boot/


Then I added an initrd line to /boot/grub/grub.cfg as shown below:

Code:
# grep -B 15 -A 1 initrd /boot/grub/grub.cfg

### BEGIN /etc/grub.d/10_linux ###
menuentry 'Gentoo GNU/Linux' --class gentoo --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-525a90f1-8ad2-44a3-ade3-20f18a0a9595' {
        load_video
        insmod gzio
        insmod part_msdos
        insmod ext2
        set root='hd0,msdos1'
        if [ x$feature_platform_search_hint = xy ]; then
          search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1  f6ffc085-66fe-4bbe-b080-cec355749f85
        else
          search --no-floppy --fs-uuid --set=root f6ffc085-66fe-4bbe-b080-cec355749f85
        fi
        echo    'Loading Linux 3.18.11-gentoo ...'
        linux   /vmlinuz-3.18.11-gentoo root=/dev/sda5 ro  drm_kms_helper.edid_firmware=edid/1920x1080_Clevo_W230SS.bin i915.modeset=1 rcutree.rcu_idle_gp_delay=1
        initrd /microcode.cpio
}


After rebooting:

Code:
# grep microcode /proc/cpuinfo
microcode       : 0x1c
microcode       : 0x1c
microcode       : 0x1c
microcode       : 0x1c
microcode       : 0x1c
microcode       : 0x1c
microcode       : 0x1c
microcode       : 0x1c
# dmesg | grep microcode
[    0.000000] CPU0 microcode updated early to revision 0x1c, date = 2014-07-03
[    0.049968] CPU1 microcode updated early to revision 0x1c, date = 2014-07-03
[    0.065070] CPU2 microcode updated early to revision 0x1c, date = 2014-07-03
[    0.080101] CPU3 microcode updated early to revision 0x1c, date = 2014-07-03
[    0.268736] microcode: CPU0 sig=0x306c3, pf=0x10, revision=0x1c
[    0.268838] microcode: CPU1 sig=0x306c3, pf=0x10, revision=0x1c
[    0.268935] microcode: CPU2 sig=0x306c3, pf=0x10, revision=0x1c
[    0.269034] microcode: CPU3 sig=0x306c3, pf=0x10, revision=0x1c
[    0.269131] microcode: CPU4 sig=0x306c3, pf=0x10, revision=0x1c
[    0.269230] microcode: CPU5 sig=0x306c3, pf=0x10, revision=0x1c
[    0.269329] microcode: CPU6 sig=0x306c3, pf=0x10, revision=0x1c
[    0.269448] microcode: CPU7 sig=0x306c3, pf=0x10, revision=0x1c
[    0.269570] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba


Note that the line 'initrd /lib/firmware/microcode.cpio' in grub.cfg does not work for me. It has to be 'initrd /microcode.cpio' and the file has to be in /boot/:

Code:
# ls /boot
System.map-3.18.11-gentoo  config-3.18.11-gentoo  grub  lost+found  microcode.cpio  vmlinuz-3.18.11-gentoo

_________________
Clevo W230SS: amd64 nvidia-drivers & xf86-video-intel.
Compal NBLB2: ~amd64 xf86-video-ati. Dual boot Win 7 Pro 64-bit.
OpenRC eudev elogind & KDE on both.

Fitzcarraldo's blog
Back to top
View user's profile Send private message
bszente
Tux's lil' helper
Tux's lil' helper


Joined: 14 Feb 2005
Posts: 123
Location: Tirgu Mures, Romania

PostPosted: Wed Aug 26, 2015 6:42 pm    Post subject: Reply with quote

Fitzcarraldo wrote:
In the Gentoo amd64 installation on my Clevo W230SS laptop I don't use an initramfs either.

In this case should the path specified in CONFIG_INITRAMFS_SOURCE be relative or absolute? In other words, should it be specified as CONFIG_INITRAMFS_SOURCE="/lib/firmware/microcode.cpio" as SpanKY wrote in Comment #41 of Bug Report #528712, or should it be specified as CONFIG_INITRAMFS_SOURCE="/microcode.cpio"? The reason I ask is because early microcode updating works for me if I leave CONFIG_INITRAMFS_SOURCE="", copy the microcode cpio file to /boot/ and add the line 'initrd /microcode.cpio' to grub.cfg as explained in detail below.


The CONFIG_INITRAMFS_SOURCE should be absolute, because it used at kernel build time. In the kernel build process that particular cpio file will be embedded in the kernel image itself. It has nothing to do with the initrd GRUB directive.

Your setup is working, because with CONFIG_INITRAMFS_SOURCE="" the kernel build process generates a dummy cpio archive (see /usr/src/linux/usr/initramfs_data.cpio.* file). Now the trick is that this archive contains the following files:
Code:
drwxr-xr-x   2 root     root            0 Aug 25 00:01 dev
crw-------   1 root     root       5,   1 Aug 25 00:01 dev/console
drwx------   2 root     root            0 Aug 25 00:01 root

Next, you specified for GRUB that it should load an external initramfs file from the boot partition, which is that microcode.cpio file. When your system boots, Grub loads this microcode.cpio file, but the kernel already has that embedded minimal cpio archive with /dev and /dev/console. Those two CPIO archives (the external microcode.cpio and embedded initramfs_data.cpio) are "merged", this is why it works for you. Will look like this:
Code:

drwxr-xr-x   2 root     root            0 Aug 25 00:01 dev
crw-------   1 root     root       5,   1 Aug 25 00:01 dev/console
drwxr-xr-x   2 root     root            0 Aug 18 21:03 kernel
drwxr-xr-x   2 root     root            0 Aug 18 21:03 kernel/x86
drwxr-xr-x   2 root     root            0 Aug 18 21:03 kernel/x86/microcode
-rw-r--r--   1 root     root       662528 Aug 18 21:03 kernel/x86/microcode/GenuineIntel.bin
drwx------   2 root     root            0 Aug 25 00:01 root

However my question was if including directly the microcode.cpio in kernel (CONFIG_INITRAMFS_SOURCE="/lib/firmware/microcode.cpio"), when that dummy cpio archive with /dev/ and /dev/console is NOT generated, should result in kernel panic or not? According to SpanKY it should not, it should boot properly. This is what I want to find out. How it is working for him? :) Can you please try this? Thanks.
Back to top
View user's profile Send private message
frostschutz
Advocate
Advocate


Joined: 22 Feb 2005
Posts: 2971
Location: Germany

PostPosted: Wed Aug 26, 2015 7:08 pm    Post subject: Reply with quote

I am using a builtin initramfs (regular initramfs as handles mdadm, luks, lvm, ...).

For early microcode loading I'm passing a microcode as initrd in GRUB.

https://wiki.gentoo.org/wiki/Intel_microcode#Early_Microcode

early microcode is necessary for intel haswell where changing microcode also changes cpu flags - which no one can really handle when the system is already running.

early microcode is special, there is no code in the microcode initrd that would contain a tool or any instruction to load microcode - the kernel does that by itself - before everything else, even before it executes the built-in initramfs.
Back to top
View user's profile Send private message
bszente
Tux's lil' helper
Tux's lil' helper


Joined: 14 Feb 2005
Posts: 123
Location: Tirgu Mures, Romania

PostPosted: Thu Aug 27, 2015 7:54 am    Post subject: Reply with quote

Hi!
frostschutz wrote:
I am using a builtin initramfs (regular initramfs as handles mdadm, luks, lvm, ...).

For early microcode loading I'm passing a microcode as initrd in GRUB.

https://wiki.gentoo.org/wiki/Intel_microcode#Early_Microcode

early microcode is necessary for intel haswell where changing microcode also changes cpu flags - which no one can really handle when the system is already running.

early microcode is special, there is no code in the microcode initrd that would contain a tool or any instruction to load microcode - the kernel does that by itself - before everything else, even before it executes the built-in initramfs.

I know that the way you described works, because you must have the proper initramfs structure in the embedded initramfs (i.e. /dev/console is not missing form the initramfs, right? check /usr/src/linux/usr/initramfs_data.cpio.* content).

If one embed in kernel ONLY the CONFIG_INITRAMFS_SOURCE="/lib/firmware/microcode.cpio initramfs WITHOUT any other external initramfs should the kernel boot properly? According to SpanKY yes, but I could not managed to do it :-) This is what I want to figure out, how is that possible. See my first post, question 1.
Back to top
View user's profile Send private message
Fitzcarraldo
Veteran
Veteran


Joined: 30 Aug 2008
Posts: 1773
Location: United Kingdom

PostPosted: Thu Aug 27, 2015 12:14 pm    Post subject: Reply with quote

bszente, in order to answer your question I rebuilt my kernel with CONFIG_INITRAMFS_SOURCE="/lib/firmware/microcode.cpio", deleted the line 'initrd /microcode' from grub.cfg, deleted the file /boot/microcode.cpio and rebooted. The kernel panicked, and the last two console lines were as follows:

Code:
[    3.142079] drm_kms_helper: panic occurred, switching back to text console
[    3.142879] ---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(8,5)


Unless SpanKY explains how he managed to get the procedure he gave in Bug Report #528712, Comment #41 to work, it seems the normal behaviour when applying the steps he gave would be for the kernel to panic. Even Gentoo developer Daniel Pielmeier experienced a kernel panic when he applied SpanKY's steps (Bug Report #528712, Comment #54).

I have reverted to using CONFIG_INITRAMFS_SOURCE="", copying /lib/firmware/microcode.cpio to /boot/microcode.cpio again and re-adding the line 'initrd /microcode.cpio' in grub.cfg.

If you ever find out how to get SpanKY's steps to work, please let us know!
_________________
Clevo W230SS: amd64 nvidia-drivers & xf86-video-intel.
Compal NBLB2: ~amd64 xf86-video-ati. Dual boot Win 7 Pro 64-bit.
OpenRC eudev elogind & KDE on both.

Fitzcarraldo's blog
Back to top
View user's profile Send private message
frostschutz
Advocate
Advocate


Joined: 22 Feb 2005
Posts: 2971
Location: Germany

PostPosted: Thu Aug 27, 2015 1:16 pm    Post subject: Reply with quote

bszente wrote:
If one embed in kernel ONLY the CONFIG_INITRAMFS_SOURCE="/lib/firmware/microcode.cpio initramfs WITHOUT any other external initramfs should the kernel boot properly?


I would expect it to work. If it boots with/out initramfs (because you don't need one?), if the options are set correctly (microcode loading builtin and early option enabled), and if the microcode.cpio is built correctly, as explained in the wiki article for early microcode loading I linked to. But I can not easily try it on my fully encrypted system. The case of not needing initramfs (apart for the microcode) simply does not exist on any on my machines.

If it does not work it would mean that whatever special handling the kernel has for microcode only exists for externally passed data, not for builtin. Although that seems odd to me. It might be possible since not many people use the builtin stuff.
Back to top
View user's profile Send private message
bszente
Tux's lil' helper
Tux's lil' helper


Joined: 14 Feb 2005
Posts: 123
Location: Tirgu Mures, Romania

PostPosted: Thu Aug 27, 2015 1:34 pm    Post subject: Reply with quote

frostschutz wrote:
bszente wrote:
If one embed in kernel ONLY the CONFIG_INITRAMFS_SOURCE="/lib/firmware/microcode.cpio initramfs WITHOUT any other external initramfs should the kernel boot properly?

I would expect it to work. If it boots with/out initramfs (because you don't need one?), if the options are set correctly (microcode loading builtin and early option enabled), and if the microcode.cpio is built correctly, as explained in the wiki article for early microcode loading I linked to.


The wiki link, you have given uses exclusive external early microcode cpio. Which will work, as I explained in my second post of this thread (the kernel build process generates that dummy minimal CPIO archive with /dev/console that will be embedded in kernel). See my second post for details.

Fitzcarraldo, thanks for your time testing the kernel panic. I will dig deeper :-)
Back to top
View user's profile Send private message
hceline
n00b
n00b


Joined: 30 Aug 2015
Posts: 36

PostPosted: Wed Sep 16, 2015 12:39 pm    Post subject: Reply with quote

frostschutz wrote:
bszente wrote:
If one embed in kernel ONLY the CONFIG_INITRAMFS_SOURCE="/lib/firmware/microcode.cpio initramfs WITHOUT any other external initramfs should the kernel boot properly?


I would expect it to work. If it boots with/out initramfs (because you don't need one?), if the options are set correctly (microcode loading builtin and early option enabled), and if the microcode.cpio is built correctly, as explained in the wiki article for early microcode loading I linked to. But I can not easily try it on my fully encrypted system. The case of not needing initramfs (apart for the microcode) simply does not exist on any on my machines.

If it does not work it would mean that whatever special handling the kernel has for microcode only exists for externally passed data, not for builtin. Although that seems odd to me. It might be possible since not many people use the builtin stuff.


I can testify that it does not work if you use efi-stub-loader with no initramfs to begin with.
For this to work on a system that boots without initramfs you have to use a boot loader like grub. Because the efi-stub-loader can not use external initramfs, and including an initramfs in the kernel does not behave the same way as loading one trough a bootloader.
Back to top
View user's profile Send private message
frostschutz
Advocate
Advocate


Joined: 22 Feb 2005
Posts: 2971
Location: Germany

PostPosted: Wed Sep 16, 2015 12:59 pm    Post subject: Reply with quote

Some people here seem to be talking about adding it as builtin firmware instead of builtin initramfs http://comments.gmane.org/gmane.linux.kernel/1898819

But I haven't tried whether that would work... and I might have misread it. It's not clear to me (from the documentation) that this is possible in any case.
Back to top
View user's profile Send private message
bszente
Tux's lil' helper
Tux's lil' helper


Joined: 14 Feb 2005
Posts: 123
Location: Tirgu Mures, Romania

PostPosted: Wed Sep 16, 2015 7:12 pm    Post subject: [SOLVED] microcode-data-20150121-r1 with USE=initramfs:panic Reply with quote

There is a conclusion now. Please see the last comments of Gentoo bug #558192 for details. Thank you everybody for the help.
Back to top
View user's profile Send private message
Fitzcarraldo
Veteran
Veteran


Joined: 30 Aug 2008
Posts: 1773
Location: United Kingdom

PostPosted: Thu Sep 17, 2015 1:24 am    Post subject: Reply with quote

Presumably there is a downside to specifying the microcode blob in the kernel configuration file, though? You would then have to rebuild the kernel each time Intel upgraded the microcode blob and you merge a new version of the package sys-apps/microcode-data. Whereas if you were to adopt the approach given in my first post, you would only need to copy the new microcode.cpio file to the boot directory:

Code:
# cp /lib/firmware/microcode.cpio /boot/


Anyway, out of interest I decided to rebuild the kernel to embed the microcode blob (I therefore also removed the line 'initrd /microcode.cpio' from grub.cfg).

Code:
Device Drivers  --->
    Generic Driver Options  --->
        (intel-ucode/06-3c-03)    External firmware blobs to build into the kernel binary
        (/lib/firmware) Firmware blobs root directory

Code:
# uname -r
3.18.11-gentoo


However the CPU microcode does not get updated when I reboot and, for some reason, my wired network connection no longer works (although my Wi-Fi connection still does).

If I use the file /lib/firmware/intel-ucode/06-3c-03 to create a file /boot/microcode.cpio manually, the CPU microcode is correctly updated at boot if I add the command 'initrd /microcode.cpio' in grub.cfg, so I know the file /lib/firmware/intel-ucode/06-3c-03 is the correct microcode blob.

What precisely is one supposed to enter in '() External firmware blobs to build into the kernel binary'?
_________________
Clevo W230SS: amd64 nvidia-drivers & xf86-video-intel.
Compal NBLB2: ~amd64 xf86-video-ati. Dual boot Win 7 Pro 64-bit.
OpenRC eudev elogind & KDE on both.

Fitzcarraldo's blog
Back to top
View user's profile Send private message
bszente
Tux's lil' helper
Tux's lil' helper


Joined: 14 Feb 2005
Posts: 123
Location: Tirgu Mures, Romania

PostPosted: Sat Sep 19, 2015 9:42 am    Post subject: Reply with quote

Fitzcarraldo wrote:
Presumably there is a downside to specifying the microcode blob in the kernel configuration file, though? You would then have to rebuild the kernel each time Intel upgraded the microcode blob and you merge a new version of the package sys-apps/microcode-data. Whereas if you were to adopt the approach given in my first post, you would only need to copy the new microcode.cpio file to the boot directory:

Code:
# cp /lib/firmware/microcode.cpio /boot/

Yes, I know it works that way, but I cannot/want to use GRUB and external Initramfs.

Fitzcarraldo wrote:
Anyway, out of interest I decided to rebuild the kernel to embed the microcode blob (I therefore also removed the line 'initrd /microcode.cpio' from grub.cfg).

Code:
Device Drivers  --->
    Generic Driver Options  --->
        (intel-ucode/06-3c-03)    External firmware blobs to build into the kernel binary
        (/lib/firmware) Firmware blobs root directory

Code:
# uname -r
3.18.11-gentoo


However the CPU microcode does not get updated when I reboot and, for some reason, my wired network connection no longer works (although my Wi-Fi connection still does).

If I use the file /lib/firmware/intel-ucode/06-3c-03 to create a file /boot/microcode.cpio manually, the CPU microcode is correctly updated at boot if I add the command 'initrd /microcode.cpio' in grub.cfg, so I know the file /lib/firmware/intel-ucode/06-3c-03 is the correct microcode blob.

What precisely is one supposed to enter in '() External firmware blobs to build into the kernel binary'?

Now that is a good question. I checked myself again, and you're right, the microcode does not get updated with this method. Apparently for AMD it works. I have to check the kernel sources to see if the intel microcode driver looks in embedded firmwares or just the initramfs file after the microcode?

PS: frostschutz's link is about this issue, perhaps that fix is not released yet. I will check it if it was merged into the kernel or not.
Back to top
View user's profile Send private message
bszente
Tux's lil' helper
Tux's lil' helper


Joined: 14 Feb 2005
Posts: 123
Location: Tirgu Mures, Romania

PostPosted: Sat Sep 19, 2015 10:08 am    Post subject: Reply with quote

This is the relevant commit. This was released in kernel 4.2.0, previous kernels look in initramfs only.
Back to top
View user's profile Send private message
bszente
Tux's lil' helper
Tux's lil' helper


Joined: 14 Feb 2005
Posts: 123
Location: Tirgu Mures, Romania

PostPosted: Sat Sep 19, 2015 11:11 am    Post subject: Reply with quote

So, I have upgraded to kernel 4.2.0 but I encountered this freeze even if I am on x86_64. So it seems, early microcode update from built in firmware does not work (yet). One must stick with (embedded) initramfs method. In embedded and no external initramfs case, don't forget to merge /lib/firmware/microcode.cpio with another CPIO archive that contains the necessary /root/ and /dev/console files.
Back to top
View user's profile Send private message
bszente
Tux's lil' helper
Tux's lil' helper


Joined: 14 Feb 2005
Posts: 123
Location: Tirgu Mures, Romania

PostPosted: Sat Sep 19, 2015 11:45 am    Post subject: Reply with quote

Further information: Early microcode loading ignores microcode provided in embedded initramfs

So this means the following for Intel early microcode update:
  1. Embedded firmware method does not work (at least on my system I get that freeze bug - see my previous post).
  2. Built in initramfs method does not work at all.
The only working solution is: external initramfs. If you cannot use external initramfs, than you are out of luck :)
Back to top
View user's profile Send private message
bszente
Tux's lil' helper
Tux's lil' helper


Joined: 14 Feb 2005
Posts: 123
Location: Tirgu Mures, Romania

PostPosted: Sat Sep 19, 2015 1:16 pm    Post subject: Reply with quote

For those who use the EFI stub loader, the initrd= option must be used for external initramfs.

In my case, the EFI System Partition (ESP) is directly mounted to /boot:
Code:
/dev/sda1               /boot           vfat            noauto,noatime  0 2

I copied the microcode file to boot (ESP) partition:
Code:
# cp /lib/firmware/microcode.cpio /boot/

Then added the EFI boot entry like this:
Code:
# efibootmgr -c -L "Gentoo Linux" -l '\vmlinuz-4.2.0-gentoo-r1' -u 'root=/dev/md0 ro rootfstype=ext4 initrd=\microcode.cpio'

After reboot the microcode is updated:
Code:
$ dmesg | grep microcode
[    0.000000] microcode: CPU0 microcode updated early to revision 0x1c, date = 2014-07-03
[    0.000000] Command line: root=/dev/md0 ro rootfstype=ext4 snd-hda-intel.id=HDMI,PCH snd-hda-intel.index=1,0 initrd=\microcode.cpio
[    0.000000] Kernel command line: root=/dev/md0 ro rootfstype=ext4 snd-hda-intel.id=HDMI,PCH snd-hda-intel.index=1,0 initrd=\microcode.cpio
[    0.000000] microcode: CPU2 microcode updated early to revision 0x1c, date = 2014-07-03
[    0.000000] microcode: CPU4 microcode updated early to revision 0x1c, date = 2014-07-03
[    0.000000] microcode: CPU6 microcode updated early to revision 0x1c, date = 2014-07-03
[    0.000000] microcode: CPU0 sig=0x306c3, pf=0x10, revision=0x1c
[    0.000000] microcode: CPU1 sig=0x306c3, pf=0x10, revision=0x1c
[    0.000000] microcode: CPU2 sig=0x306c3, pf=0x10, revision=0x1c
[    0.000000] microcode: CPU3 sig=0x306c3, pf=0x10, revision=0x1c
[    0.000000] microcode: CPU4 sig=0x306c3, pf=0x10, revision=0x1c
[    0.000000] microcode: CPU5 sig=0x306c3, pf=0x10, revision=0x1c
[    0.000000] microcode: CPU6 sig=0x306c3, pf=0x10, revision=0x1c
[    0.000000] microcode: CPU7 sig=0x306c3, pf=0x10, revision=0x1c
[    0.000000] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum