intel / Intel-Linux-Processor-Microcode-Data-Files

Other
620 stars 68 forks source link

When will be version 150 released? #39

Closed Enerccio closed 3 years ago

Enerccio commented 3 years ago

Linux is stuck at v120

esyr-rh commented 3 years ago

Why, exactly, are you expecting this particular revision of (presumably) 06-7e-05 microcode?

Enerccio commented 3 years ago

Well I am having issues with 120 which is latest that was fixed at least in 150 (but for apple). This is the issue: https://youtrack.jetbrains.com/issue/JBR-2310

esyr-rh commented 3 years ago

On Thu, Aug 13, 2020 at 09:40:46AM -0700, Enerccio wrote:

Well I am having issues with 120 which is latest that was fixed at least in 150 (but for apple). This is the issue: https://youtrack.jetbrains.com/issue/JBR-2310

What issues? Random panics/reboots on MacBook Air 2020/Surface Pro when using NetBeans IDE?

Meanwhile, one can grab revision 0x96 of 06-7e-05 microcode at [1]. There is also an earlier revision 0x46 available, as a part of microcode-20191112..microcode-20191115 releases [2].

[1] https://github.com/platomav/CPUMicrocodes/blob/master/Intel/cpu706E5_plat80_ver00000096_2020-06-16_PRD_4A457385.bin [2] https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/blob/microcode-20191115/intel-ucode/06-7e-05

vanushwashere commented 3 years ago

What issues? Random panics/reboots on MacBook Air 2020/Surface Pro when using NetBeans IDE?

It happens 10 times in a row in an hour with all JetBrains programs and on all Ice Lake CPUs, hangs everything and requires force restart. It is very annoying.

vanushwashere commented 3 years ago

Here is the official statement: https://youtrack.jetbrains.com/issue/JBR-2310#focus=Comments-27-4260299.0-0

dcaillibaud commented 3 years ago

For the ones who read this thread without any idea on how update manually their microcode, here is what I did. It works for me but don't do this if you don't understand what's happening ! Don't blame me if it breaks your system, and be sure to have another way to boot (rescue mode, boot without any initrd, etc.) before doing this.

First I download https://github.com/platomav/CPUMicrocodes/blob/master/Intel/cpu706E5_plat80_ver00000096_2020-06-16_PRD_4A457385.bin and put it in /boot (my only partition without crypto).

Then, after reading some howto I manually add a line in /boot/grub/grub.cfg to load this microcode before initrd

        linux   /vmlinuz-5.7.0-0.bpo.2-amd64 root=/dev/mapper/nvme-root ro  quiet
        initrd  /cpu706E5_plat80_ver00000096_2020-06-16_PRD_4A457385.bin
        initrd  /initrd.img-5.7.0-0.bpo.2-amd64

but it doesn't change anything, after a boot I'm still with microcode 0x78 (120). If it works for you and you want to stay like this don't forget to make this change in a better way (update-grub will erase this addon on next run), depending on your distro.

So I decided to use iucode_tool to upgrade my initrd (I'm on debian with intel-microcode and iucode-tool packages installed)

# first let's see what iucode_tool detect
/usr/sbin/iucode_tool -tb -lS /lib/firmware/intel-ucode/* /boot/cpu706E5_plat80_ver00000096_2020-06-16_PRD_4A457385.bin 
/usr/sbin/iucode_tool: system has processor(s) with signature 0x000706e5
[…]
selected microcodes:
  059/001: sig 0x000706e5, pf_mask 0x80, 2020-03-12, rev 0x0078, size 107520

# ok, 78 is the one actually loaded, as shown by `grep microcode /proc/cpuinfo`
# what would happen adding the new dowloaded one
/usr/sbin/iucode_tool -tb -lS /lib/firmware/intel-ucode/* /boot/cpu706E5_plat80_ver00000096_2020-06-16_PRD_4A457385.bin 
/usr/sbin/iucode_tool: system has processor(s) with signature 0x000706e5
[…]
selected microcodes:
  082/001: sig 0x000706e5, pf_mask 0x80, 2020-06-16, rev 0x0096, size 108544

# ok, the download one is seen as a better one (0x0096 => 9×16+6 = 150)
# so we add it to the list in /lib/firmware/intel-ucode
iucode-tool -v --write-firmware /boot/cpu706E5_plat80_ver00000096_2020-06-16_PRD_4A457385.bin
iucode-tool: processed 1 valid microcode(s), 1 signature(s), 1 unique signature(s)
iucode-tool: selected 1 microcode(s), 1 signature(s)
iucode-tool: Writing microcode firmware file(s) into /lib/firmware/intel-ucode
iucode-tool: 06-7e-05: cannot write to, or create file: File exists
iucode-tool: no files were written into /lib/firmware/intel-ucode

# well, we already have a 06-7e-05, let's move it (naming it as dpkg could do, but you can name it as you like)
mv /lib/firmware/intel-ucode/06-7e-05 /lib/firmware/intel-ucode/06-7e-05.dpkg-dist

# new try
iucode-tool -v --write-firmware /boot/cpu706E5_plat80_ver00000096_2020-06-16_PRD_4A457385.bin
iucode-tool: processed 1 valid microcode(s), 1 signature(s), 1 unique signature(s)
iucode-tool: selected 1 microcode(s), 1 signature(s)
iucode-tool: Writing microcode firmware file(s) into /lib/firmware/intel-ucode
iucode-tool: 06-7e-05: 1 microcode entries written, 108544 bytes
iucode-tool: 1 file(s) were written into /lib/firmware/intel-ucode

# ok, juste check this new one will be selected
/usr/sbin/iucode_tool -tb -lS /lib/firmware/intel-ucode/*
[…]
selected microcodes:
  059/001: sig 0x000706e5, pf_mask 0x80, 2020-06-16, rev 0x0096, size 108544

# update initrd
update-initramfs -u

And after a reboot, grep microcode /proc/cpuinfo show 0x96.

I hope it will solve my repeated OS crash using jetbrain IDE, and hope it helps somebody else.

Enerccio commented 3 years ago

well the official arch ones come from this repository, this is why I asked when it will be updated :(

hmh commented 3 years ago

Debian and Ubuntu will happily accept extra microcode updates if you place them in /usr/share/misc/intel-microcode-SOMEDESCRIPTIONHERE.bin.

This has the advantage (or disadvantage, depending on what you really want) that the microcode update has far better chances to survive an intel-microcode package update. Note that the above is not valid for any systems using dracut (even Debian/Ubuntu ones): it is a feature of the initramfs-tools helper used in Debian and Ubuntu's intel-microcode package.

Note that this only allows one to add newer microcode updates: iucode_tool (as used by the Debian/Ubuntu initramfs helpers) will pick the newest one (as in "highest revision") it can find from /usr/share/misc/intel-microcode and /lib/firmware/intel-ucode/

You need to run "update-initramfs -u" to get the system to install the microcode update to the initramfs, and reboot to apply it.

You can check which microcode updates are in the initramfs images in /boot using: /usr/sbin/iucode_tool -tr -L /boot/initrd.img*

(adjust the iucode_tool command above to the path and filenames of your system's initramfs images).

And yes, if you can observe the malfunctions described in the JetBrains report on hardware running Linux, we'd really like Intel to issue a new official microcode update package, pretty please, so that we can distribute those to the end-users...

acfsmith commented 3 years ago

Link to microcode revision 0x96 of 06-7e-05 doesn't work anymore. Looks like new version available here: https://github.com/platomav/CPUMicrocodes/blob/master/Intel/cpu706E5_plat80_ver0000009E_2020-07-22_PRD_06DDA133.bin. I hope it will solve problem. Any hints how to setup it in Arch based distros?

acfsmith commented 3 years ago

Ok, I found way to test new microcode by myself. It is very easy in Manjaro (and I believe any other Arch based distros). Install iucode-tool. Download microcode to /tmp. Cast some spells:

mkdir /lib/firmware/intel-ucode iucode_tool -v --write-firmware /tmp/cpu706E5_plat80_ver0000009E_2020-07-22_PRD_06DDA133.bin echo 1 > /sys/devices/system/cpu/microcode/reload cat /proc/cpuinfo | grep microcode

Now it says I have version 0x9e. It is time to start CLion and start coding to test new firmware ;)

bsdice commented 3 years ago

echo 1 > /sys/devices/system/cpu/microcode/reload

Not every microcode is safe to be hot-loaded while the OS is running! AFAIK there is no documentation aside from internal Intel/Microsoft documents that state if this is safe. If you are really into it you can observe what Microsoft is doing on Windows regarding microcode updates.

After been bitten by bad microcode myself I advise for Arch Linux to just downgrade motherboard BIOS and package intel-ucode (using "downgrade" package and command) to a known-good version and also add intel-ucode package to IgnorePkg line in pacman.conf. This will prevent inadvertent updates in the future. Arch will take what upstream (Intel) is putting out, not really good for stability, sadly.

acfsmith commented 3 years ago

I doesn't found any problems yet. CLion works well for me now. Can't test anymore because of my notebook runs out of battery and my daughter runs out of patience :) Upgrade may be not safe, but looks like it finally solved my problems.

dcaillibaud commented 3 years ago

No more jetbrains IDE crash since microcode update to 0x96 revision.

Thanks to @hmh and his easier solution to update microcode (than mine), and with the new microcode 9e given by @acfsmith I'm running with 0x9e revision, let's see if it remains stable…

Enerccio commented 3 years ago

why won't this repo be updated with 0x96 revision? Arch linux relies on this repo to update and I don't want to do manual update!

bulletmark commented 3 years ago

@Enerccio, note current version is actually 0xa0 (i.e. 160).

esyr-rh commented 3 years ago

06-7e-05 microcode is updated to revision 0xa0 with microcode-20201110 release.