Bug 1501362

Not sure this bug should be filed against dracut like the bug report below:
https://bugzilla.redhat.com/show_bug.cgi?id=1476039

And if this didn't get fix, it should be a blocker for f27
Its a huge deal before fixing anything else if the cpu doesn't work properly

Proposed as a Blocker and Freeze Exception for 27-final by Fedora user truboxl using the blocker tracking app because:

 Affects some Intel hardware not update microcode early (to the latest version), may cause lockups.
Should be fixed before anything else

I just tried ubuntu-17.10-beta2-desktop-amd64.iso on the same machine and got the same behavior (TSC_Deadline disabled, update to microcode 0x25).

I don't think this really a case of "CPU doesn't work properly", per http://wiki.osdev.org/APIC_timer tsc-deadline mode is a relatively new and certainly 'optional' feature (everything will work without it). Older CPUs don't have it at all.

So I don't think this is a blocker, but shipping the updated microcode would be good to avoid 'worrying' messages like this, so I'm probably +1 FE. Re-assigning to appropriate package; Anton, it looks like the Intel microcode in the package hasn't been updated since 20170707?

This bug also happens with Ubtuntu 17.10-beta2: https://bugs.launchpad.net/ubuntu/+source/evince/+bug/1724650

I'd expect it'll happen on anything that has a sufficiently recent kernel but not a sufficiently recent set of Intel microcode updates.

Hello Chatty,

could you attach a text file here with the output of following commands, after you booted cleanly (without forcing microcode load manually)
# dmidecode -t 4
# cat /proc/cpuinfo
# dmesg
# rpm -q microcode_ctl
# ls -l /lib/firmware/intel-ucode/

thanks,

Created attachment 1341448 [details]
Info of cpuinfo, dmesg, ...

Two x86-apic patches on TSC_DEADLINE  waiting 
in https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree/queue-4.13

However doesn't match fully issue conditions.

Discussed during the 2017-10-23 blocker review meeting: [1]

The decision to classify this bug as a RejectedBlocker and a RejectedFreezeException was made as this seems to only be a warning about a possible feature that could be implemented and rushing to fix/add it could be potentially dangerous.

[1] https://meetbot.fedoraproject.org/fedora-blocker-review/2017-10-23/f27-blocker-review.2017-10-23-16.00.txt

The solution to this bug is very easy: I inserted intel_ucode.img (taken from archlinux-2017.10.01-x86_64.iso) as first initrd and rawhide booted with TSC enabled as it should.

In my case (Fedora 27-beta live image, Asus motherboard, Intel i7) the error message is

[Firmware Bug]: TSC_DEADLINE disabled due to Errata; please update microcode to version: 0x22 (or later).

After this message two dracut-pre-udev messages and 2 messages from my sd drive are displayed and then the system hangs -> I can't boot the kernel on the live image!

Does it work with the updated microcode (see #11).

Does it work with the updated microcode (see #11)?

Thomas: it's very unlikely the hang has anything to do with the message. You just happen to notice the message because the system hangs; if it didn't, the message would be displayed but you probably wouldn't notice it.

microcode_ctl-2.1-19.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-c8f03e1046

Note that my issue reported in comment 12 seems to be solved with the final F27 live image. I still get microcode warning, though.

Please also update Rawhide. Fedora-Workstation-Live-x86_64-Rawhide-20171123 still doesn't boot without manually inserting the microcode update.

microcode_ctl-2.1-19.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-c8f03e1046

microcode_ctl-2.1-19.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.

This package needs to be integrated into the installation ISO otherwise affected systems can't boot! This means, this bug is not yet resolved!

Please tell me in which ISO it is integrated so I can test?

It is not, and we have no plans to respin the installer images at this time. So far you're the only person reporting that this somehow prevents your system from booting; I haven't seen any other report of this. Anton, did the information Chatty provided in #c8 tell you anything interesting?

It happens on the Surface Book which I'm sure quite a lot of people own. Mine is updated to the most recent version. I hope Microsoft will fix the Intel ME security flaw along with the microcode any time soon but so far they didn't.

If you don't fix it for F27 it would be great if you fix it at least for F28 onwards.

(In reply to Adam Williamson from comment #22)
> It is not, and we have no plans to respin the installer images at this time.
> So far you're the only person reporting that this somehow prevents your
> system from booting; I haven't seen any other report of this. Anton, did the
> information Chatty provided in #c8 tell you anything interesting?

Adam, not really. I still have no idea about the nature of this issue and how exactly it was fixed. Intel doesn't tell anything about the firmware blobs and the issues it fixes. That said, if this update helped - we may hope that it was fixed and it wasn't just a coincidence.

I have no idea how popular Surface Book is, so can't tell whether we want to respin the installer images. I tend to think - in case it would be a big issue we would have more reports.

Due to the nature of the bug (happening so early in the boot process) I guess most people don't know what to report as they can't come up with logs etc. Having said that I am also surprised that there are so little reports as this affects all recent distros. Anyway, I've got my workaround (µcode update as first initrd).

If we don't want to respin ISOs there are some workarounds which I believe should work, although not easy:
 - 1) Install F26 and update to F27 latest
 - 2) Configure Anaconda via kickstart to enable the update repo for installation rather that the GA repo. Anaconda will then install the updated package directly.

Network installs have the updates repository enabled by default.

I'm seeing the same issue with the F27 Live ISO on a Surface Book w/ Performance Base as well. I'm currently making an F26 image, but can confirm Chatty's exact experience.

Thanks for the confirmation. I'll write up a note for Common Bugs documenting the case for the Surface Book...

This bug appears to have been reported against 'rawhide' during the Fedora 28 development cycle.
Changing version to '28'.

Intel Rolls Out Updated, Post-Spectre CPU Microcode (20180312), will it be included in update rpm?

microcode_ctl-2.1-22.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-5767adea74

microcode_ctl-2.1-22.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2018-172ca25120

microcode_ctl-2.1-22.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-172ca25120

microcode_ctl-2.1-22.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-5767adea74

Fedora 28 here, microcode is not auto updated.

microcode_ctl-2.1-22.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.

microcode_ctl-2.1-22.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.

Chatty, Bojan - could either of you check whether F28 images boot OK on the Surface Book? Thanks!

All images (even the one's from bug report date) are booting now since Microsoft updated the UEFI bios (and the microcode) due to Spectre and Meltdown as I reported already here: https://bugzilla.redhat.com/show_bug.cgi?id=1500057#c6

I can however test a current image on my Medion S6417 laptop whether TSC_DEADLINE error is fixed.

Well, all images are booting *so long as you've updated the system firmware*, I guess. Thanks for the info.

Created attachment 1450329 [details]
Requested infos

I am still seeing this annoying message with an updated Fedora 28. Is it expected?

Created attachment 1456975 [details]
Test if microcode is vulernable to meltdown (as in if the microcode has been successfully applied / is complete as supplied from Intel).

(In reply to Julien HENRY from comment #42)
> Created attachment 1450329 [details]
> Requested infos
> 
> I am still seeing this annoying message with an updated Fedora 28. Is it
> expected?

I second this, either the microcode is not properly updated or it's incomplete.

I'm on Fedora Atomic Workstation r28 with initramfs regeneration enabled, package installed, dracut -fv doesn't change anything either. All updates applied. 

The microcode just won't get updated. See the spectre-meltdown checker script above. Intel Core I5 6200

$ cat /proc/cpuinfo
processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 78
model name	: Intel(R) Core(TM) i5-6200U CPU @ 2.30GHz
stepping	: 3
microcode	: 0x33
cpu MHz		: 800.022
cache size	: 3072 KB
physical id	: 0
siblings	: 4
core id		: 0
cpu cores	: 2
apicid		: 0
initial apicid	: 0
fpu		: yes
fpu_exception	: yes
cpuid level	: 22
wp		: yes
flags		: 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 art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single pti tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp
bugs		: cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass
bogomips	: 4800.00
clflush size	: 64
cache_alignment	: 64
address sizes	: 39 bits physical, 48 bits virtual
power management:

Created attachment 1456976 [details]
spectre-meltdown-checker for my i5-4670K

I have attached the output of spectre-meltdown-checker

Intel still has not released microcode updates for everything, though they did post a new bundle on 7/03. Microcode_ctl should be updated with this at some point very soon.

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days