Bug 1005585

besides the above this new package replacing the service does *not* work
in the past you needed only to replace /usr/lib/firmware/microcode.dat and restart the service, now calling "intel-microcode2ucode" shows the update *but* it is not used at reboot nor applied at runtime

for now i took the src.rpm, replace the microcode-traball from intel with the new one and the same name and rebuilt the packge with rpmbuild and voila after boot it is applied

holy hell that *can not* be the way to go for an ordinary user who cares and does not want until someone is so gently and update the package itself

[    3.095769] microcode: CPU0 sig=0x306a9, pf=0x2, revision=0x12
[    3.140811] microcode: CPU0 sig=0x306a9, pf=0x2, revision=0x12
[    3.141384] microcode: CPU0 updated to revision 0x19, date = 2013-06-13
[    3.141474] microcode: CPU1 sig=0x306a9, pf=0x2, revision=0x12
[    3.141589] microcode: CPU1 sig=0x306a9, pf=0x2, revision=0x12
[    3.141918] microcode: CPU1 updated to revision 0x19, date = 2013-06-13
[    3.141994] microcode: CPU2 sig=0x306a9, pf=0x2, revision=0x12
[    3.142087] microcode: CPU2 sig=0x306a9, pf=0x2, revision=0x12
[    3.142407] microcode: CPU2 updated to revision 0x19, date = 2013-06-13
[    3.142483] microcode: CPU3 sig=0x306a9, pf=0x2, revision=0x12
[    3.142613] microcode: CPU3 sig=0x306a9, pf=0x2, revision=0x12
[    3.142930] microcode: CPU3 updated to revision 0x19, date = 2013-06-13
[    3.143003] microcode: CPU4 sig=0x306a9, pf=0x2, revision=0x12
[    3.143085] microcode: CPU4 sig=0x306a9, pf=0x2, revision=0x12
[    3.143403] microcode: CPU4 updated to revision 0x19, date = 2013-06-13
[    3.143476] microcode: CPU5 sig=0x306a9, pf=0x2, revision=0x12
[    3.143591] microcode: CPU5 sig=0x306a9, pf=0x2, revision=0x12
[    3.143921] microcode: CPU5 updated to revision 0x19, date = 2013-06-13
[    3.143994] microcode: CPU6 sig=0x306a9, pf=0x2, revision=0x12
[    3.144081] microcode: CPU6 sig=0x306a9, pf=0x2, revision=0x12
[    3.144397] microcode: CPU6 updated to revision 0x19, date = 2013-06-13
[    3.144478] microcode: CPU7 sig=0x306a9, pf=0x2, revision=0x12
[    3.144593] microcode: CPU7 sig=0x306a9, pf=0x2, revision=0x12
[    3.144921] microcode: CPU7 updated to revision 0x19, date = 2013-06-13

Harald,

Yeah, Fedora 19 was updated with this microcode almost a month ago, and I didn't push the same update for Fedora 18. Will do in a few.

You don't need a user-space helper(nor system service) to load the Intel's microcode anymore. Linux kernel /catches/ the microcode itself from the /lib/firmware directory.

If you want to update it yourself, use "intel-microcode2ucode" utility to translate the microcode.dat file into ucode data, and put this data to /lib/firmware/intel-ucode directory. reboot.

Anton

microcode_ctl-2.0-4.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/microcode_ctl-2.0-4.fc18

> use "intel-microcode2ucode" utility to translate the microcode.dat file

how?
this tool does not have any help option nor a manpage

calling "intel-microcode2ucode" gives a output i would expect with the new file at /usr/lib/firmware/microcode.dat and honestly normally i would expect that at the same time it get installed

BTW: 
i do not see any improvement in the new microcode_ctl given that
a) it is does not what a enduser expects
b) it needs a reboot to load the new microcode

in the past you simply refreshed /usr/lib/firmware/microcode.dat and restarted the no longer existing microcode_ctl service *without* reboot

Harald, I agree, it is not straightforward and you are welcome to write a help for the tool.

Once you refresh the data in /lib/firmware/intel-ucode/, you can do:
# modprobe -r microcode
# modprobe microcode
this way you will get an updated microcode applied without reboot.

Note, that very soon microcode_ctl will not exist at all. We are just waiting for the Intel to integrate their bits into "linux-firmware" package. (AMD already did this)

Note 2: You may have even newer microcode from 20130906, you may want it if you run Haswell CPU. Find it here: https://fedorahosted.org/microcode_ctl, both tarballs v1.23 and v2.1-2 has it inside.

hope this help,
and cheers,
Anton

Sandy Bridge / Ivy Bridge

the package i downloaded yesterday applies 2013-06-12 on the SamdyBridge and so i guess it looks what CPU needs what microcode, confirmed also for the koji package

Sep 09 12:17:35 Updated: 2:microcode_ctl-2.0-4.fc18.x86_64

> Once you refresh the data in /lib/firmware/intel-ucode/, you can do:
> # modprobe -r microcode
> # modprobe microcode
> this way you will get an updated microcode applied without reboot

calling intel-microcode2ucode does *not* refresh /lib/firmware/intel-ucode/ even with a recent /usr/lib/firmware/microcode.dat and IMHO *that* is a bug because i have no idea how to refresh /lib/firmware/intel-ucode/ at all

that this goes into linux-firmware is nice but i doubt that the linux-firmware package is always recent and in case of CPU bugs i for mysself does not want to wait

(In reply to Harald Reindl from comment #6)
> Sandy Bridge / Ivy Bridge
> 
> the package i downloaded yesterday applies 2013-06-12 on the SamdyBridge and
> so i guess it looks what CPU needs what microcode, confirmed also for the
> koji package
> 
> Sep 09 12:17:35 Updated: 2:microcode_ctl-2.0-4.fc18.x86_64

Yes, correct,
...
[    3.141589] microcode: CPU1 sig=0x306a9, pf=0x2, revision=0x12
[    3.141918] microcode: CPU1 updated to revision 0x19, date = 2013-06-13
...
from your dmesg you see that CPU was updated from rev. 0x12 to 0x19(dated 2013-06-13). If newer(20130808+) microcode update does not update *this* CPU it just means that *this* CPU is not vulnerable and doesn't require an update.

Anton.

(In reply to Harald Reindl from comment #7)
> > Once you refresh the data in /lib/firmware/intel-ucode/, you can do:
> > # modprobe -r microcode
> > # modprobe microcode
> > this way you will get an updated microcode applied without reboot
> 
> calling intel-microcode2ucode does *not* refresh /lib/firmware/intel-ucode/
> even with a recent /usr/lib/firmware/microcode.dat and IMHO *that* is a bug
> because i have no idea how to refresh /lib/firmware/intel-ucode/ at all
> 
> that this goes into linux-firmware is nice but i doubt that the
> linux-firmware package is always recent and in case of CPU bugs i for
> mysself does not want to wait

Yes, it doesn't, it just saves the parsed microcode.dat into intel-ucode directory to the same location where "intel-microcode2ucode" was executed.

We expect, only tech-savvy person will go manual way and it will not make him a problem, others - will do 'yum update'.


If you want to do it manually:

Put the microcode.dat to /tmp/ucode, and:
[anton@bandura ~]$ cd /tmp/ucode/
[anton@bandura ucode]$ ls
microcode.dat
[anton@bandura ucode]$ intel-microcode2ucode microcode.dat 
microcode.dat: 576512(563k) bytes, 144128 integers

intel-ucode/0f-00-0a
signature: 0xf0a
flags:     0x02
revision:  0x15
date:      2002-08-21
size:      2048

[...snip...]

intel-ucode/06-1e-04
signature: 0x106e4
flags:     0x09
revision:  0x03
date:      2013-07-01
size:      6144

[anton@bandura ucode]$ ls -l
total 1696
drwxr-x--- 2 anton anton    1540 Sep  9 12:44 intel-ucode
-rw-r--r-- 1 anton anton 1734491 Sep  6 08:21 microcode.dat

[anton@bandura ucode]$ mv intel-ucode/ /lib/firmware/

And either reboot or reload microcode kernel module to apply the microcode.

microcode_ctl-2.0-5.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/microcode_ctl-2.0-5.fc18

Package microcode_ctl-2.0-5.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing microcode_ctl-2.0-5.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-16186/microcode_ctl-2.0-5.fc18
then log in and leave karma (feedback).

microcode_ctl-2.0-5.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.