12 replies to this topic

[abarbarian]

Quote

Originally shared by nixCraft
Affects all oses. Updated can be applied by updating your UEFI/BIOS microcode update for CPU. Make sure you apply those fixes.


[WARNING] Intel Skylake/Kaby Lake processors: broken hyper-threading
[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]. [WARNING] Intel Skylake/Kaby Lake processors: broken hyper-threading. To: debian-user@lists.debian.org, debian-devel@lists.debian.org; Subject: [WARNING] Intel Skylake/Kaby Lake processors: broken hyper-threading ...
lists.debian.org

There is a warning circulating G+ regarding newer intel cpu's if you have one of these cpu's you would benefit from reading the info.

I am trying to find out if my Arch has or will supply updates to the microcode via normal updates or if I need to take action.

[securitybreach]

Well do you have one of those processors? You can easily update your microcode https://wiki.archlin...p/microcode  

Although, you shouldn't have to it very often as they only come out once a blue moon.

[abarbarian]

securitybreach, on 29 June 2017 - 09:05 AM, said:

Well do you have one of those processors? You can easily update your microcode https://wiki.archlin...code Â

Although, you shouldn't have to it very often as they only come out once a blue moon.

Yup I got one of them there fancy shmancy cpu's an it is a 94/3 so I will be affected.

I followed the wiki when I set up and it looks like I have a "intel-ucode.img" in my EFI folder.

I was just a little confused as to if the new update will be included with the Arch updates as the Debian info says to do a manual update.

I can not follow the wikis advice to try and run iucode-tool as it will not install,

Verifying source file signatures with gpg...
iucode-tool_2.1.2.tar.xz ... FAILED (unknown public key FE11BFA68B158E98)
==> ERROR: One or more PGP signatures could not be verified!
:: failed to verify iucode-tool integrity

I am also having some slight problems with refind. The only way I can get the pc to boot at the moment is with this line in my  refind_linux,conf,

"Boot with standard options" "ro root=/dev/nvme0n1p4"

I have tried several different ways to alter this line. Following advice from the forums where a  similar problem was solved by this type of entry,

"Boot with standard options" "ro root=/dev/nvme0n1p4 initrd=/boot/intel-ucode.img initrd=/boot/initramfs-linux.img"

which seems to me to be in line with the information from the refind home page and the advice on the wiki.
However this does not work for me. I have "ro" but the wiki gives "rw" don't know if that makes a difference, and the wiki also has "quiet" which I do not have, but I do not think that they make a difference to booting.

So I am in a bit of a pickle. Been meaning to sort out the booting issue but got caught up with Steam and monsters in the metro

Thoughts help advice a fix would be most appreciated.

Oh an I ain't swapping out refind for anything else. I done too much reading up to can it now. Plus I am a stubborn son of a ********

Edited by abarbarian, 29 June 2017 - 11:58 AM.

[abarbarian]

Solved the problem of getting the gpg key. Seems the author of the program can not be bothered to construct his package properly.

Quote

I am the iucode_tool upstream author. If you cannot find my gnupg key, please try to fetch it from the keyserver network I use:

hkps.pool.sks-keyservers.net

Note that this is a hkp*S* keyserver pool, so you can (should) use TLS to connect to it.

There are other sks-keyservers.net keyservers, which should also have my gnupg key. Please refer to: https://sks-keyservers.net/

OTOH, if you problem is how to get the fetched key into the correct local keyring that Arch linux will use to validate the download, that I cannot help you with.

Seems a bit not right to me.

[securitybreach]

Yeah, any time you get an error on AUR packages, always check the webpage for the package as you will mostly always find the fix in the comments.

[Digerati]

My bold added:

Quote

Yup I got one of them there fancy shmancy cpu's...so I will be affected.

How do you know? Have you been experiencing unexplained stability issues?

This is certainly not good but I note the bug has only been exposed under very remote, extreme circumstances while running benchmark programs crunching complex equations with very large numbers. In other words, in synthetic scenarios. It has not - yet - been reported to cause problems with users performing normal tasks, including games.

So the recommendation cited in that original Debian.org article that apparently went viral is simply wrong, IMO. They recommend disabling hyperthreading now, "just in case you run afoul of its potentially quite serious problems."

"Just in case"? Come on! That's putting the cart in front of the horse, IMO. If not been experiencing stability issues, there is no reason to panic and start making changes to our systems.

For the record, I have one of the affected Skylake processors (i5-6600) in this computer and it has been running just fine since I put it together back in February 2016. I am not going to disable hyperthreading now. I will keep an eye out for BIOS updates on my motherboard's webpage and "IF" I am experiencing problems an update addresses, then I will update my system.

[abarbarian]

Digerati, on 29 June 2017 - 12:45 PM, said:

My bold added:

Quote

Yup I got one of them there fancy shmancy cpu's...so I will be affected.

How do you know? Have you been experiencing unexplained stability issues?

This is certainly not good but I note the bug has only been exposed under very remote, extreme circumstances while running benchmark programs crunching complex equations with very large numbers. In other words, in synthetic scenarios. It has not - yet - been reported to cause problems with users performing normal tasks, including games.

So the recommendation cited in that original Debian.org article that apparently went viral is simply wrong, IMO. They recommend disabling hyperthreading now, "just in case you run afoul of its potentially quite serious problems."

"Just in case"? Come on! That's putting the cart in front of the horse, IMO. If not been experiencing stability issues, there is no reason to panic and start making changes to our systems.

For the record, I have one of the affected Skylake processors (i5-6600) in this computer and it has been running just fine since I put it together back in February 2016. I am not going to disable hyperthreading now. I will keep an eye out for BIOS updates on my motherboard's webpage and "IF" I am experiencing problems an update addresses, then I will update my system.

Well I ain't as far as I know had any problems.  There have been quite a few bios updates for the mobo since I built so I will update those at some point. The mobo site shows the last microcode update as being in 2015 so they are not offering this new one but then again mobo manufactures do not always keep up to date with support.

I am more inclined to spend time on my boot problem which has me baffled.

[Digerati]

I think this is a smart approach. While updating the BIOS is a much more reliable and safe process than it was a few years ago, if something goes wrong (like a power outage right in the middle of the flash - been there ) a corrupt flash can still brick a motherboard.

[goretsky]

Hello,

I don't have many devices affected by this, but the new laptop I got for myself last year had a BIOS (well, UEFI, actually) firmware update to fix this.  I wold imagine other computer and motherboard manufacturers are doing the same thing?

Regards,

Aryeh Goretsky

[abarbarian]

Digerati, on 29 June 2017 - 01:40 PM, said:

I think this is a smart approach. While updating the BIOS is a much more reliable and safe process than it was a few years ago, if something goes wrong (like a power outage right in the middle of the flash - been there ) a corrupt flash can still brick a motherboard.

Good job my mobo has two set of bios, at least I get two goes at bricking me pc. It usually takes me two goes to get things right.

[Digerati]

Quote

Good job my mobo has two set of bios

My Gigabyte does too. Though I have never had to resort to the backup/secondary BIOS, it is reassuring knowing it is there.

[abarbarian]

Digerati, on 30 June 2017 - 12:21 PM, said:

Quote

Good job my mobo has two set of bios

My Gigabyte does too. Though I have never had to resort to the backup/secondary BIOS, it is reassuring knowing it is there.

I have done bios updates on four mobos three of them form different manufacturers and had no problems. Guess I have been lucky. Mind you all of them used locally downloaded bios either from within the running os or from a usb. Maybe in the past if you were installing from the net you may have had problems with dodgy internet connections and such like.

[Digerati]

Over the many years, I've done 100s. Including way back in the olden days when updating the BIOS required replacing the PROM. Then to update, to actually "flashing" by erasing the EPROMs with a high intensity UV light. It was nice when EEPROMs came along. But as I noted, and as most motherboard makers note on their BIOS update pages, this is still a risky task. I never update a BIOS unless the system is on a decent UPS.