| View previous topic :: View next topic |
| Author |
Message |
bszente
Tux's lil' helper
Joined: 14 Feb 2005
Posts: 123
Location: Tirgu Mures, Romania
|
 Posted: Tue Aug 25, 2015 8:27 pm Post subject: [SOLVED] microcode-data-20150121-r1 with USE=initramfs:panic |
 |
|
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:
- Upgrading to sys-apps/microcode-ctl-1.28-r1 the init scripts vanished
- I carefully read the microcode-ctl-1.28-r1.ebuild
- 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:
- 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?
- 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 |
|
 |
Fitzcarraldo
Advocate
Joined: 30 Aug 2008
Posts: 2034
Location: United Kingdom
|
| Posted: Wed Aug 26, 2015 5:44 pm Post subject: |
|
|
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, VIDEO_CARDS="intel modesetting nvidia".
Compal NBLB2: ~amd64, xf86-video-ati. Dual boot Win 7 Pro 64-bit.
OpenRC udev elogind & KDE on both.
Fitzcarraldo's blog |
|
| Back to top |
|
|
bszente
Tux's lil' helper
Joined: 14 Feb 2005
Posts: 123
Location: Tirgu Mures, Romania
|
| Posted: Wed Aug 26, 2015 6:42 pm Post subject: |
|
|
| 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 |
|
|
frostschutz
Advocate
Joined: 22 Feb 2005
Posts: 2977
Location: Germany
|
| Posted: Wed Aug 26, 2015 7:08 pm Post subject: |
|
|
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 |
|
|
bszente
Tux's lil' helper
Joined: 14 Feb 2005
Posts: 123
Location: Tirgu Mures, Romania
|
| Posted: Thu Aug 27, 2015 7:54 am Post subject: |
|
|
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 |
|
|
Fitzcarraldo
Advocate
Joined: 30 Aug 2008
Posts: 2034
Location: United Kingdom
|
| Posted: Thu Aug 27, 2015 12:14 pm Post subject: |
|
|
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, VIDEO_CARDS="intel modesetting nvidia".
Compal NBLB2: ~amd64, xf86-video-ati. Dual boot Win 7 Pro 64-bit.
OpenRC udev elogind & KDE on both.
Fitzcarraldo's blog |
|
| Back to top |
|
|
frostschutz
Advocate
Joined: 22 Feb 2005
Posts: 2977
Location: Germany
|
| Posted: Thu Aug 27, 2015 1:16 pm Post subject: |
|
|
| 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 |
|
|
bszente
Tux's lil' helper
Joined: 14 Feb 2005
Posts: 123
Location: Tirgu Mures, Romania
|
| Posted: Thu Aug 27, 2015 1:34 pm Post subject: |
|
|
| 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 |
|
|
hceline
n00b
Joined: 30 Aug 2015
Posts: 36
|
| Posted: Wed Sep 16, 2015 12:39 pm Post subject: |
|
|
| 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 |
|
|
frostschutz
Advocate
Joined: 22 Feb 2005
Posts: 2977
Location: Germany
|
| Posted: Wed Sep 16, 2015 12:59 pm Post subject: |
|
|
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 |
|
|
bszente
Tux's lil' helper
Joined: 14 Feb 2005
Posts: 123
Location: Tirgu Mures, Romania
|
| Posted: Wed Sep 16, 2015 7:12 pm Post subject: [SOLVED] microcode-data-20150121-r1 with USE=initramfs:panic |
|
|
| 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 |
|
|
Fitzcarraldo
Advocate
Joined: 30 Aug 2008
Posts: 2034
Location: United Kingdom
|
| Posted: Thu Sep 17, 2015 1:24 am Post subject: |
|
|
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, VIDEO_CARDS="intel modesetting nvidia".
Compal NBLB2: ~amd64, xf86-video-ati. Dual boot Win 7 Pro 64-bit.
OpenRC udev elogind & KDE on both.
Fitzcarraldo's blog |
|
| Back to top |
|
|
bszente
Tux's lil' helper
Joined: 14 Feb 2005
Posts: 123
Location: Tirgu Mures, Romania
|
| Posted: Sat Sep 19, 2015 9:42 am Post subject: |
|
|
| 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 |
|
|
bszente
Tux's lil' helper
Joined: 14 Feb 2005
Posts: 123
Location: Tirgu Mures, Romania
|
| Posted: Sat Sep 19, 2015 10:08 am Post subject: |
|
|
| This is the relevant commit. This was released in kernel 4.2.0, previous kernels look in initramfs only. |
|
| Back to top |
|
|
bszente
Tux's lil' helper
Joined: 14 Feb 2005
Posts: 123
Location: Tirgu Mures, Romania
|
| Posted: Sat Sep 19, 2015 11:11 am Post subject: |
|
|
| 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 |
|
|
bszente
Tux's lil' helper
Joined: 14 Feb 2005
Posts: 123
Location: Tirgu Mures, Romania
|
| Posted: Sat Sep 19, 2015 11:45 am Post subject: |
|
|
Further information: Early microcode loading ignores microcode provided in embedded initramfs
So this means the following for Intel early microcode update:- Embedded firmware method does not work (at least on my system I get that freeze bug - see my previous post).
- 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 |
|
|
bszente
Tux's lil' helper
Joined: 14 Feb 2005
Posts: 123
Location: Tirgu Mures, Romania
|
| Posted: Sat Sep 19, 2015 1:16 pm Post subject: |
|
|
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 |
|
|
|
|
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
|
|
Kernel & Hardware
