I ask about this on account of boot delays reported in the following:
http://www.spinics.net/lists/linux-initramfs/msg04173.html
http://www.spinics.net/lists/linux-initramfs/msg04175.html
http://www.spinics.net/lists/linux-initramfs/msg04275.html
I was looking at early portions of dmesg for anything resembling clues and
noticed that early microcode messages are not always reported for every core
present. Here are examples of 'dmesg | grep croco', all taken from machines
with two cpu cores. Notice that some refer to two different cores, while
others make no mention of the existence of more than one core:
Linux big31 4.7.4-200.fc24.x86_64 #1 SMP Thu Sep 15 18:42:09 UTC 2016 x86_64
x86_64 x86_64 GNU/Linux
[ 0.000000] microcode: microcode updated early to revision 0xa0b, date =
2010-09-28
[ 0.835393] microcode: CPU0 sig=0x1067a, pf=0x1, revision=0xa0b
[ 0.840090] microcode: CPU1 sig=0x1067a, pf=0x1, revision=0xa0b
Linux big31 4.8.8-200.fc24.x86_64 #1 SMP Tue Nov 15 19:41:51 UTC 2016 x86_64
x86_64 x86_64 GNU/Linux
[ 0.000000] microcode: microcode updated early to revision 0xa0b, date =
2010-09-28
[ 0.851345] microcode: sig=0x1067a, pf=0x1, revision=0xa0b
Linux big31 4.8.0-0.rc8.git0.1.fc25.x86_64 #1 SMP Mon Sep 26 17:12:24 UTC
2016 x86_64 x86_64 x86_64 GNU/Linux
[ 0.000000] microcode: microcode updated early to revision 0xa0b, date =
2010-09-28
[ 0.830256] microcode: sig=0x1067a, pf=0x1, revision=0xa0b
Linux big31 4.8.8-300.fc25.x86_64 #1 SMP Tue Nov 15 18:10:06 UTC 2016 x86_64
x86_64 x86_64 GNU/Linux
[ 0.000000] microcode: microcode updated early to revision 0xa0b, date =
2010-09-28
[ 0.601683] microcode: sig=0x1067a, pf=0x1, revision=0xa0b
Linux big31 4.8.0-0.rc1.git3.1.fc26.x86_64 #1 SMP Thu Aug 11 01:00:58 UTC
2016 x86_64 x86_64 x86_64 GNU/Linux
[ 0.000000] microcode: microcode updated early to revision 0xa0b, date =
2010-09-28
[ 1.157172] microcode: sig=0x1067a, pf=0x1, revision=0xa0b
Linux big31 4.8.0-0.rc8.git1.1.fc26.x86_64 #1 SMP Wed Sep 28 23:21:40 UTC
2016 x86_64 x86_64 x86_64 GNU/Linux
[ 0.000000] microcode: microcode updated early to revision 0xa0b, date =
2010-09-28
[ 0.965454] microcode: sig=0x1067a, pf=0x1, revision=0xa0b
Linux big31 4.9.0-0.rc5.git4.1.fc26.x86_64 #1 SMP Fri Nov 18 17:52:58 UTC
2016 x86_64 x86_64 x86_64 GNU/Linux
[ 0.000000] microcode: microcode updated early to revision 0xa0b, date =
2010-09-28
[ 1.146158] microcode: sig=0x1067a, pf=0x1, revision=0xa0b
Linux big41 4.6.5-300.fc24.x86_64 #1 SMP Thu Jul 28 01:10:12 UTC 2016 x86_64
x86_64 x86_64 GNU/Linux
[ 0.000000] microcode: microcode updated early to revision 0xa0b, date =
2010-09-28
[ 0.716008] microcode: CPU0 sig=0x1067a, pf=0x1, revision=0xa0b
[ 0.716801] microcode: CPU1 sig=0x1067a, pf=0x1, revision=0xa0b
Linux big41 4.8.7-200.fc24.x86_64 #1 SMP Fri Nov 11 15:44:18 UTC 2016 x86_64
x86_64 x86_64 GNU/Linux
[ 0.000000] microcode: microcode updated early to revision 0xa0b, date =
2010-09-28
[ 0.617156] microcode: sig=0x1067a, pf=0x1, revision=0xa0b
Is it possible that the varying reference or not to CPUx is indicative of
some kind of installation mishandling lurking in microcode installation,
possibly causing microcode to be installed in only one of the two cores,
which could be at root of or affecting the boot initialization delay
described in my linux-initramfs posts? If so, should I file a bug? If yes, in
which tracker, and against which component (kernel? dracut? microcode_ctl?
other?).
--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
_______________________________________________
kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx
