|
Bugzilla – Full Text Bug Listing |
| Summary: | Boot Probleme with Intel Microcode on Core i7 6800K (Broadwell E) and latest Intel microcode | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE Distribution | Reporter: | Andras Fabian <andras.fabian> |
| Component: | Kernel | Assignee: | Borislav Petkov <bpetkov> |
| Status: | RESOLVED FIXED | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P1 - Urgent | CC: | achen35, arvidjaar, bpetkov, forgotten_FgJdweZ8xB, graham.anderson, jkosina, manfred.h, meissner |
| Version: | Leap 42.3 | ||
| Target Milestone: | --- | ||
| Hardware: | x86-64 | ||
| OS: | openSUSE 42.3 | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: |
Broadwell E dmesg with `dis_ucode_ldr` boot option
Broadwell E cpuinfo dmesg rev 0xb000025 Screenshot of where the computer freezes |
||
This looks strange. I built ucode-intel myself based on the latest microcode updates from Intel and from Base:System for openSUSE_Leap_42.2 and 42.3 and used it successfully to boot on all my systems (Intel Haswell, Kaby Lake and some older CPU); it might be useful to remember that no foreign graphics card is used in any of my systems. Perhaps you might want to try if the following package helps with your case: <https://download.opensuse.org/repositories/home:/mhnovell/openSUSE_Leap_42.3/x86_64/ucode-intel-20171117-4.1.x86_64.rpm> Hi Manfred, I quickly downloaded and extracted the contents of your recommended RPM ... And I am almost 100% sure (sorry, have a long running job in the background and can't reboot for now), this would NOT fix my problem, as when I check it with (the grep string is the CPU ID as identified with "iucode_tool -S") iucode_tool -L ucode-intel-20171117-4.1.x86_64/ | grep 0x000406f1 I get the same 3 entries: 089/001: sig 0x000406f1, pf_mask 0xef, 2017-03-01, rev 0xb000021, size 26624 089/002: sig 0x000406f1, pf_mask 0xef, 2017-03-01, rev 0xb000021, size 26624 089/003: sig 0x000406f1, pf_mask 0xef, 2017-11-18, rev 0xb000025, size 27648 As with the "official" 20170707-13.1.x86_64.rpm (2017-11-18): 085/001: sig 0x000406f1, pf_mask 0xef, 2017-03-01, rev 0xb000021, size 26624 085/002: sig 0x000406f1, pf_mask 0xef, 2017-03-01, rev 0xb000021, size 26624 085/003: sig 0x000406f1, pf_mask 0xef, 2017-11-18, rev 0xb000025, size 27648 Both contain that "ominous" 2017-11-18 entry ... which - as it seemed by my "investigation" - was quite likely the culprit (which completely froze my entire machine the moment the "loading initial ramdisk" started) What I find still puzzling is, where you (SUSE) did get that 2017-11-18 entry from, when the - current - official (and seemingly latest) Intel download does not have this entry at all (I had the link in my original bug report)? This official Intel download still only contains one single entry for my CPU: 089/001: sig 0x000406f1, pf_mask 0xef, 2017-03-01, rev 0xb000021, size 26624 Also you list a lot of CPUs you tested on ... but not a "Broadwell E" (or at least you do not mention). And as far as I understand, the ucode package is not a global microcode set used for all CPUs identically, but it contains a lot of tiny microcode blobs, where only one of them - the latest and with the right ID - is applied to your CPU based on what CPU one has. Which of course makes sense, as microcode sets will quite likely greatly differ among different CPU lines / generations. the received ucode from intel to help with problems and it seems it does not work as advertised. we need to revert this i think Can you send full dmesg after booting with "dis_ucode_ldr" and /proc/cpuinfo from the box? Created attachment 755173 [details]
Broadwell E dmesg with `dis_ucode_ldr` boot option
I have a Broadwell E and find the same boot issue, above dis_ucode_ldr boot option also lets me boot. Here's the dmesg output and cpuinfo to follow
Created attachment 755175 [details]
Broadwell E cpuinfo
cpuinfo
(In reply to Graham Anderson from comment #5) > Created attachment 755173 [details] > Broadwell E dmesg with `dis_ucode_ldr` boot option > > I have a Broadwell E and find the same boot issue, above dis_ucode_ldr boot > option also lets me boot. Here's the dmesg output and cpuinfo to follow How are you loading your microcode? initrd or late? If you don't know, please downgrade the microcode package and send full dmesg again. Or does it say something like this in some of your old dmesgs in /var/log "CPU%d microcode updated early to revision 0x".. Thx. Created attachment 755187 [details] dmesg (In reply to Borislav Petkov from comment #7) > (In reply to Graham Anderson from comment #5) > > Created attachment 755173 [details] > > Broadwell E dmesg with `dis_ucode_ldr` boot option > > > > I have a Broadwell E and find the same boot issue, above dis_ucode_ldr boot > > option also lets me boot. Here's the dmesg output and cpuinfo to follow > > How are you loading your microcode? initrd or late? initrd I believe Jan 08 14:18:12 excession kernel: microcode: CPU0 microcode updated early to revision 0xb000021, date = 2017-03-01 For completeness I've attached dmesg output from booting with ucode-intel @ 20170707-10.1 Since it was mentioned earlier in the bud I've also tried booting without the nvidia kmp etc and same issue occurs. I see the same early loading. Which is quite likely initrd (and it fails immediately when "loading initial ramdisk" comes up). My latest dmesg shows it (I just grep-ed out the "micro" keyword): -------------------------------------------------------------------- [ 0.000000] microcode: CPU0 microcode updated early to revision 0xb000021, date = 2017-03-01 [ 0.146162] microcode: CPU1 microcode updated early to revision 0xb000021, date = 2017-03-01 [ 0.150639] microcode: CPU2 microcode updated early to revision 0xb000021, date = 2017-03-01 [ 0.155136] microcode: CPU3 microcode updated early to revision 0xb000021, date = 2017-03-01 [ 0.159619] microcode: CPU4 microcode updated early to revision 0xb000021, date = 2017-03-01 [ 0.164112] microcode: CPU5 microcode updated early to revision 0xb000021, date = 2017-03-01 [ 0.168613] microcode: CPU6 microcode updated early to revision 0xb000021, date = 2017-03-01 [ 0.173094] microcode: CPU7 microcode updated early to revision 0xb000021, date = 2017-03-01 [ 2.034728] microcode: CPU0 sig=0x406f1, pf=0x4, revision=0xb000021 [ 2.034744] microcode: CPU1 sig=0x406f1, pf=0x4, revision=0xb000021 [ 2.034759] microcode: CPU2 sig=0x406f1, pf=0x4, revision=0xb000021 [ 2.034772] microcode: CPU3 sig=0x406f1, pf=0x4, revision=0xb000021 [ 2.034785] microcode: CPU4 sig=0x406f1, pf=0x4, revision=0xb000021 [ 2.034798] microcode: CPU5 sig=0x406f1, pf=0x4, revision=0xb000021 [ 2.034814] microcode: CPU6 sig=0x406f1, pf=0x4, revision=0xb000021 [ 2.034829] microcode: CPU7 sig=0x406f1, pf=0x4, revision=0xb000021 [ 2.034843] microcode: CPU8 sig=0x406f1, pf=0x4, revision=0xb000021 [ 2.034854] microcode: CPU9 sig=0x406f1, pf=0x4, revision=0xb000021 [ 2.034867] microcode: CPU10 sig=0x406f1, pf=0x4, revision=0xb000021 [ 2.034879] microcode: CPU11 sig=0x406f1, pf=0x4, revision=0xb000021 [ 2.034893] microcode: CPU12 sig=0x406f1, pf=0x4, revision=0xb000021 [ 2.034906] microcode: CPU13 sig=0x406f1, pf=0x4, revision=0xb000021 [ 2.034919] microcode: CPU14 sig=0x406f1, pf=0x4, revision=0xb000021 [ 2.034932] microcode: CPU15 sig=0x406f1, pf=0x4, revision=0xb000021 [ 2.034993] microcode: Microcode Update Driver: v2.01 <tigran@aivazian.fsnet.co.uk>, Peter Oruba -------------------------------------------------------------------- In case you want to try Intel's plain firmware package, I built a new package with the firmware-CVE-2017-5715.tar.gz tarball being removed. You can download it from <https://download.opensuse.org/repositories/home:/mhnovell/openSUSE_Leap_42.3/x86_64/ucode-intel-20171117-5.1.x86_64.rpm> (In reply to Manfred Hollstein from comment #10) > In case you want to try Intel's plain firmware package, I built a new > package with the firmware-CVE-2017-5715.tar.gz tarball being removed. You > can download it from > <https://download.opensuse.org/repositories/home:/mhnovell/openSUSE_Leap_42. > 3/x86_64/ucode-intel-20171117-5.1.x86_64.rpm> Please do not confuse them. The microcode patch we're carrying is for the bugs the whole world is talking about and that is not yet in the download center. > initrd I believe > > Jan 08 14:18:12 excession kernel: microcode: CPU0 microcode updated early to revision 0xb000021, date = 2017-03-01 Yes, thanks! > Since it was mentioned earlier in the bud I've also tried booting without the nvidia kmp etc and same issue occurs. Nah, that's shouldn't affect this. Ok, so both of you have 0x4f model which gets updated early to revision 0xb000021 just fine. Good. Now, Andras, where did you get this other microcode on your system? 085/001: sig 0x000406f1, pf_mask 0xef, 2017-03-01, rev 0xb000021, size 26624 085/002: sig 0x000406f1, pf_mask 0xef, 2017-03-01, rev 0xb000021, size 26624 085/003: sig 0x000406f1, pf_mask 0xef, 2017-11-18, rev 0xb000025, size 27648 The only one you should have is: $ sha1sum /lib/firmware/intel-ucode/06-4f-01 94fcef18562a56872353e8cc5a3f10a60b4724b4 /lib/firmware/intel-ucode/06-4f-01 which is 001/001: sig 0x000406f1, pf_mask 0xef, 2017-11-18, rev 0xb000025, size 27648 can you check whether this is the case? All others need to go. Same for you Graham. Then please rebuild your initrds: # mkinitrd as root and reboot. I am sceptical this would work but it is worth a try. Thx. Hi Borislav, I received that set of 3 ucode entries (as pointed out in my first bug report) simply with the latest official OepnSUSE update package: ucode-intel-20170707-13.1.x86_64.rpm http://download.opensuse.org/update/leap/42.3/oss/x86_64/ucode-intel-20170707-13.1.x86_64.rpm If you download that now and simply extract the RPM, you will quite likely see the same three entries with "iucode_tool -L ucode-intel-20170707-13.1.x86_64/ | grep 0x000406f1" (where "ucode-intel-20170707-13.1.x86_64" is the folder where I extracted the intel-ucode folder from the RPM). And I highly suspect, that exactly that latest 2017-11-18 entry is "hosing" the Broadwell E CPUs. Ok, I'm attaching only the latest microcode patch from Intel: 40270ff77e3065a617f60d5b1661a702588fdb3f 06-4f-01 Please replace your file /lib/firmware/intel-ucode/06-4f-01 with it, after verifying the sha1sum, recreate the initrd and try booting. Thx. Created attachment 755209 [details]
rev 0xb000025
Hi Borislav, I did exactly as you requested. Replaced my local firmware /lib/firmware/intel-ucode/06-4f-01 with you bin and let mkinitrd run. Then reboot, and -a as expected - again a complete system freeze. Now I reverted back to my previous microcode file (coming from ucode-intel-20170511-8.1.x86_64.rpm) and everything is running nicely again (containing the double 2017-03-01, rev 0xb000021 entry). So, I think this gun is smoking quite strongly ... Broadwell E's do not go well with the 2017-11-18, rev 0xb000025 microcode. Ok, cool, thanks for testing. Just to make sure I've understood you correctly: your system freezes right after: loading initial ramdisk yes? Thanks. Created attachment 755215 [details]
Screenshot of where the computer freezes
Hi Borislav, As my "screenshot" (classic photo with mobile - as its hard to make native captures on a frozen computer :-D ) shows, thats exactly where the computer freezes. Yeah, that could be anywhere early within the boot. And yes, this is how we all still debug laptops, with a phone camera, in 2018. There's simply no other way. :-( Ok, let's see what Intel says first. Thx. Ok, can you guys try this kernel: https://download.opensuse.org/repositories/home:/bpetkov:/42.3-bdw/standard/ and enable the *latest* microcode which fails. I'd like to see whether it is caused by the microcode loading itself or by the detection of spec_ctrl later. Thanks. (clear needinfo). (In reply to Borislav Petkov from comment #21) > Ok, can you guys try this kernel: > > https://download.opensuse.org/repositories/home:/bpetkov:/42.3-bdw/standard/ > > and enable the *latest* microcode which fails. > > I'd like to see whether it is caused by the microcode loading itself or > by the detection of spec_ctrl later. > > Thanks. > > (clear needinfo). Same freeze at same location with kernel 4.4.107-1.ga865915-default from your repo and microcode ucode-intel-20170707-13.1 (In reply to Borislav Petkov from comment #21) > (clear needinfo). Sorry couldn't see way to unset this (In reply to Graham Anderson from comment #22) > Same freeze at same location with kernel 4.4.107-1.ga865915-default from > your repo and microcode ucode-intel-20170707-13.1 Good, that confirms that it is the loading itself. Thanks! > Sorry couldn't see way to unset this It is normally under the input box. But no biggie, all good :-) Thanks Graham for testing, because (I wrote off list to Borislav) today I would not have time to test it on my computer. But this then - it seems - confirms that indeed the microcode has some "nice" regression. Now it seems, there is a new round of official Intel Microcodes: https://downloadcenter.intel.com/download/27431/Linux-Processor-Microcode-Data-File?v=t Dated: 20180108 But they still omit the Broadwell E (even though, they intend to support it too with a fixed microcode). I checked previous and this package: iucode_tool -L microcode-20171117/intel-ucode/ | grep 0x000406f1 089/001: sig 0x000406f1, pf_mask 0xef, 2017-03-01, rev 0xb000021, size 26624 iucode_tool -L microcode-20180108/intel-ucode/ | grep 0x000406f1 089/001: sig 0x000406f1, pf_mask 0xef, 2017-03-01, rev 0xb000021, size 26624 So, still the old, last working 2017-03-01, rev 0xb000021 in it. (In reply to Andras Fabian from comment #26) > But they still omit the Broadwell E (even though, they intend to support it Yes, it was pulled because of this issue. I'll let you know if there's something to test. Thx. SUSE-RU-2018:0430-1: An update that has two recommended fixes can now be installed. Category: recommended (important) Bug References: 1074919,1079890 CVE References: Sources used: SUSE OpenStack Cloud 6 (src): ucode-intel-20180108.revertto20170707-13.14.1 SUSE Linux Enterprise Server for SAP 12-SP1 (src): ucode-intel-20180108.revertto20170707-13.14.1 SUSE Linux Enterprise Server 12-SP3 (src): ucode-intel-20180108.revertto20170707-13.14.1 SUSE Linux Enterprise Server 12-SP2 (src): ucode-intel-20180108.revertto20170707-13.14.1 SUSE Linux Enterprise Server 12-SP1-LTSS (src): ucode-intel-20180108.revertto20170707-13.14.1 SUSE Linux Enterprise Server 12-LTSS (src): ucode-intel-20180108.revertto20170707-13.14.1 SUSE Linux Enterprise Desktop 12-SP3 (src): ucode-intel-20180108.revertto20170707-13.14.1 SUSE Linux Enterprise Desktop 12-SP2 (src): ucode-intel-20180108.revertto20170707-13.14.1 This is an autogenerated message for OBS integration: This bug (1074919) was mentioned in https://build.opensuse.org/request/show/577716 42.3 / ucode-intel openSUSE-RU-2018:0478-1: An update that has two recommended fixes can now be installed. Category: recommended (important) Bug References: 1074919,1079890 CVE References: Sources used: openSUSE Leap 42.3 (src): ucode-intel-20180108.revertto20170707-19.1 Ok, I've backported the microcode blackisting from upstream http://kernel.suse.com/cgit/kernel/commit/?h=openSUSE-42.3&id=c07ad6ffaba857bcf401058927be5ad5c0859e8b so we should be blacklisting the same microcode revisions as upstream now. If you guys wanna give it a try, leap KOTD has it already: http://kernel.suse.com/packages/openSUSE-42.3 I'm closing. Feel free to reopen if you still encounter issues. SUSE-SU-2018:2092-1: An update that solves 22 vulnerabilities and has 246 fixes is now available. Category: security (important) Bug References: 1046303,1046305,1046306,1046307,1046540,1046542,1046543,1048129,1050242,1050252,1050529,1050536,1050538,1050545,1050549,1050662,1051510,1052766,1055968,1056427,1056643,1056651,1056653,1056657,1056658,1056662,1056686,1056787,1058115,1058513,1058659,1058717,1060463,1061024,1061840,1062897,1064802,1065600,1066110,1066129,1068032,1068054,1071218,1071995,1072829,1072856,1073513,1073765,1073960,1074562,1074578,1074701,1074741,1074873,1074919,1075006,1075007,1075262,1075419,1075748,1075876,1076049,1076115,1076372,1076830,1077338,1078248,1078353,1079152,1079747,1080039,1080542,1081599,1082485,1082504,1082869,1082962,1083647,1083900,1084001,1084570,1085308,1085539,1085626,1085933,1085936,1085937,1085938,1085939,1085941,1086282,1086283,1086286,1086288,1086319,1086323,1086400,1086652,1086739,1087078,1087082,1087084,1087092,1087205,1087210,1087213,1087214,1087284,1087405,1087458,1087939,1087978,1088354,1088690,1088704,1088722,1088796,1088804,1088821,1088866,1089115,1089268,1089467,1089608,1089663,1089664,1089667,1089669,1089752,1089753,1089878,1090150,1090457,1090605,1090643,1090646,1090658,1090734,1090888,1090953,1091158,1091171,1091424,1091594,1091666,1091678,1091686,1091781,1091782,1091815,1091860,1091960,1092100,1092472,1092710,1092772,1092888,1092904,1092975,1093023,1093027,1093035,1093118,1093148,1093158,1093184,1093205,1093273,1093290,1093604,1093641,1093649,1093653,1093655,1093657,1093663,1093721,1093728,1093904,1093990,1094244,1094356,1094420,1094541,1094575,1094751,1094825,1094840,1094912,1094978,1095042,1095094,1095115,1095155,1095265,1095321,1095337,1095467,1095573,1095735,1095893,1096065,1096480,1096529,1096696,1096705,1096728,1096753,1096790,1096793,1097034,1097105,1097234,1097356,1097373,1097439,1097465,1097468,1097470,1097471,1097472,1097551,1097780,1097796,1097800,1097941,1097961,1098016,1098043,1098050,1098174,1098176,1098236,1098401,1098425,1098435,1098599,1098626,1098706,1098983,1098995,1099029,1099041,1099109,1099142,1099183,1099715,1099792,1099918,1099924,1099966,1100132,1100209,1100340,1100362,1100382,1100394,1100416,1100418,1100491,1100602,1100633,1100843,1101296,1101315,1101324,971975,975772 CVE References: CVE-2017-5715,CVE-2017-5753,CVE-2018-1000200,CVE-2018-1000204,CVE-2018-10087,CVE-2018-10124,CVE-2018-1092,CVE-2018-1093,CVE-2018-1094,CVE-2018-1118,CVE-2018-1120,CVE-2018-1130,CVE-2018-12233,CVE-2018-13053,CVE-2018-13405,CVE-2018-13406,CVE-2018-3639,CVE-2018-5803,CVE-2018-5848,CVE-2018-7492,CVE-2018-8781,CVE-2018-9385 Sources used: SUSE Linux Enterprise Workstation Extension 15 (src): kernel-default-4.12.14-25.3.1 SUSE Linux Enterprise Module for Live Patching 15 (src): kernel-default-4.12.14-25.3.1, kernel-livepatch-SLE15_Update_1-1-1.3.1 SUSE Linux Enterprise Module for Legacy Software 15 (src): kernel-default-4.12.14-25.3.1 SUSE Linux Enterprise Module for Development Tools 15 (src): kernel-docs-4.12.14-25.3.1, kernel-obs-build-4.12.14-25.3.1, kernel-source-4.12.14-25.3.1, kernel-syms-4.12.14-25.3.1, kernel-vanilla-4.12.14-25.3.1 SUSE Linux Enterprise Module for Basesystem 15 (src): kernel-default-4.12.14-25.3.1, kernel-source-4.12.14-25.3.1, kernel-zfcpdump-4.12.14-25.3.1 SUSE Linux Enterprise High Availability 15 (src): kernel-default-4.12.14-25.3.1 openSUSE-SU-2018:2119-1: An update that solves 23 vulnerabilities and has 283 fixes is now available. Category: security (important) Bug References: 1022476,1046303,1046305,1046306,1046307,1046540,1046542,1046543,1048129,1050242,1050252,1050529,1050536,1050538,1050545,1050549,1050662,1051510,1052766,1055117,1055186,1055968,1056427,1056643,1056651,1056653,1056657,1056658,1056662,1056686,1056787,1058115,1058513,1058659,1058717,1059336,1060463,1061024,1061840,1062897,1064802,1065600,1065729,1066110,1066129,1068032,1068054,1068546,1071218,1071995,1072829,1072856,1073513,1073765,1073960,1074562,1074578,1074701,1074741,1074873,1074919,1074984,1075006,1075007,1075262,1075419,1075748,1075876,1076049,1076115,1076372,1076830,1077338,1078248,1078353,1079152,1079747,1080039,1080157,1080542,1081599,1082485,1082504,1082869,1082962,1083647,1083684,1083900,1084001,1084570,1084721,1085308,1085341,1085400,1085539,1085626,1085933,1085936,1085937,1085938,1085939,1085941,1086224,1086282,1086283,1086286,1086288,1086319,1086323,1086400,1086467,1086652,1086739,1087084,1087088,1087092,1087205,1087210,1087213,1087214,1087284,1087405,1087458,1087939,1087978,1088273,1088354,1088374,1088690,1088704,1088713,1088722,1088796,1088804,1088821,1088866,1088872,1089074,1089086,1089115,1089141,1089198,1089268,1089271,1089467,1089608,1089644,1089663,1089664,1089667,1089669,1089752,1089753,1089762,1089878,1089889,1089977,1090098,1090150,1090457,1090522,1090534,1090535,1090605,1090643,1090646,1090658,1090717,1090734,1090818,1090888,1090953,1091101,1091158,1091171,1091264,1091424,1091532,1091543,1091594,1091666,1091678,1091686,1091781,1091782,1091815,1091860,1091960,1092100,1092289,1092472,1092566,1092710,1092772,1092888,1092904,1092975,1093023,1093027,1093035,1093118,1093148,1093158,1093184,1093205,1093273,1093290,1093604,1093641,1093649,1093653,1093655,1093657,1093663,1093721,1093728,1093904,1093990,1094244,1094356,1094420,1094541,1094575,1094751,1094825,1094840,1094978,1095042,1095094,1095104,1095115,1095155,1095265,1095321,1095337,1095467,1095573,1095735,1095893,1096065,1096480,1096529,1096696,1096705,1096728,1096753,1096790,1096793,1097034,1097105,1097234,1097356,1097373,1097439,1097465,1097468,1097470,1097471,1097472,1097551,1097780,1097796,1097800,1097941,1097961,1098016,1098043,1098050,1098174,1098176,1098236,1098401,1098425,1098435,1098599,1098626,1098706,1098983,1098995,1099029,1099041,1099109,1099142,1099183,1099715,1099792,1099918,1099924,1099966,1100132,1100209,1100340,1100362,1100382,1100416,1100418,1100491,1100602,1100633,1100734,1100843,1101296,1101315,1101324,971975,975772 CVE References: CVE-2017-5715,CVE-2017-5753,CVE-2018-1000200,CVE-2018-1000204,CVE-2018-10087,CVE-2018-10124,CVE-2018-10323,CVE-2018-1092,CVE-2018-1093,CVE-2018-1094,CVE-2018-1108,CVE-2018-1118,CVE-2018-1120,CVE-2018-1130,CVE-2018-12233,CVE-2018-13053,CVE-2018-13405,CVE-2018-13406,CVE-2018-5803,CVE-2018-5848,CVE-2018-7492,CVE-2018-8781,CVE-2018-9385 Sources used: openSUSE Leap 15.0 (src): kernel-debug-4.12.14-lp150.12.7.1, kernel-default-4.12.14-lp150.12.7.1, kernel-docs-4.12.14-lp150.12.7.1, kernel-kvmsmall-4.12.14-lp150.12.7.1, kernel-obs-build-4.12.14-lp150.12.7.1, kernel-obs-qa-4.12.14-lp150.12.7.1, kernel-source-4.12.14-lp150.12.7.1, kernel-syms-4.12.14-lp150.12.7.1, kernel-vanilla-4.12.14-lp150.12.7.1 |
After an update on Friday (2017-01-05) to kernel : 4.4.104-39.1 ucode-intel : 20170707-13.1 My computer didn't boot anymore and was hanging in the "loading initial ramdisk" screen. After some researching and experimenting, I got the tip to try disabling the loading of custom microcode with the kernel parameter "dis_ucode_ldr" (which prevents the loading of any custom ucode)! As soon as I did this, I could again boot my machine without any problems. This then brought me the idea, to check what has been updated in the microcode area, and indeed, there was that latest ucode-intel update: 20170707-13.1 After reverting back to an old ucode-intel (20170511-8.1) - and locking it until things get fixed - I can normally boot up without the need to use "dis_ucode_ldr". -------------------------------- I also checked a little bit, what kind of microcode updates I got. First I scanned for my CPU ID with iucode_tool: iucode_tool: system has processor(s) with signature 0x000406f1 Then looked with iucode_tool what was included in ucode-intel-20170707-13.1.x86_64.rpm: 085/001: sig 0x000406f1, pf_mask 0xef, 2017-03-01, rev 0xb000021, size 26624 085/002: sig 0x000406f1, pf_mask 0xef, 2017-03-01, rev 0xb000021, size 26624 085/003: sig 0x000406f1, pf_mask 0xef, 2017-11-18, rev 0xb000025, size 27648 Its quite likely, that the latest line (with date 2017-11-18) was / is the culprit, as it seems to be a relatively new ucode! But what made me really surprised was, when I checked what the latest - downloadable - Intel (official) packaes includes which one can download here https://downloadcenter.intel.com/download/27337/Linux-Processor-Microcode-Data-File There you get the latest 20171117.tgz .... and this one only offers one ucode for my CPU: 089/001: sig 0x000406f1, pf_mask 0xef, 2017-03-01, rev 0xb000021, size 26624 So, obviously there is some confusion on what should be in the current ucode package ... Maybe Intel already removed the ucode update for my CPU because they know that it created some issues? What I also find interesting that the latest ucode-intel-20170707-13.1.x86_64.rpm with the 2017-11-18 entry seems to be newer than what is on the official Intel Download. For the moment it seems that at least my CPU don't boot (or hang) when it gets treated with the latest ucode. Thus maybe - for now - its better to stay with an older (but stable) ucode package on CPUs which exhibit these issues. -------------------------------- My lscpu Architektur: x86_64 CPU Operationsmodus: 32-bit, 64-bit Byte-Reihenfolge: Little Endian CPU(s): 16 Liste der Online-CPU(s):0-15 Thread(s) pro Kern: 2 Kern(e) pro Socket: 8 Sockel: 1 NUMA-Knoten: 1 Anbieterkennung: GenuineIntel Prozessorfamilie: 6 Modell: 79 Modellname: Intel(R) Core(TM) i7-6900K CPU @ 3.20GHz Stepping: 1 CPU MHz: 3700.029 Maximale Taktfrequenz der CPU:4000,0000 Minimale Taktfrequenz der CPU:1200,0000 BogoMIPS: 6399.48 Virtualisierung: VT-x L1d Cache: 32K L1i Cache: 32K L2 Cache: 256K L3 Cache: 20480K NUMA-Knoten0 CPU(s): 0-15 Markierungen: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch ida arat invpcid_single pln pts dtherm intel_pt kaiser tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm cqm rdseed adx smap xsaveopt cqm_llc cqm_occup_llc --------------------------------