Debian Warns Of Hyper Threading Issue With Intel Sky/Kaby Lake CPUs

[bridgman]

DRM doesn't work. That doesn't stop evil corporations that are stuck smelling each others farts from pretending that it does though.

The point is not whether it works. The point is that compliance with standards in that area is required in order for us (and our competitors) to be able to sell products in most of our markets. That second point is outside our control and not subject to debate, unfortunately.

[BaronHK]

The point is not whether it works. The point is that compliance with standards in that area is required in order for us (and our competitors) to be able to sell products in most of our markets. That second point is outside our control and not subject to debate, unfortunately.

Meh, AMD is a giant trash fire anyway.

[bridgman]

Meh, AMD is a giant trash fire anyway.

???

Nothing I said was specific to AMD, I'm talking about industry requirements that all the competitors need to support.

[waxhead]

They ship without firmware and then stand there like the retarded stepchild when computers malfunction because of it. You think you're not running "non-free microcode" because you don't have the Debian package installed? WRONG! You're just running an old version with bugs as loaded by your BIOS! Debian's policies mean that unless the user configures their computer the way Debian should have done it, then this FIXED bug could be provoked and result in a disaster complete with data loss.

Review of Debian 9: Broken Broken Broken Stupid Stupid Stupid. Full Stop. There doesn't exist a universe where "We're going to leave you with the equally non-free broken BIOS-provided firmware instead of shipping the patch." makes sense.

Which x86 processor that anyone other than Richard Stallman would want to use doesn't have non-free firmware?

I know that Debian supports a lot of architectures that aren't very important in the grand scheme of things (I mean, up until recently, if you wanted to dust off your PowerPC Mac from when dinosaurs roamed the Earth and have Debian stop to fix issues with it as if it was as important as x86, you found your distro), but probably upwards of 90% use it on x86, and most distributions don't even support more than x86 and maybe a few arm devices. Fedora has even de-prioritized 32-bit x86 to the point where problems that only affect that version don't get to block a release.

First of all, Debian is NOT the problem here. It is the faulty hardware.
Second: Debian allows you to correct the problem by installing non-free software anyway. Just not by default.
Third: You seem to miss the point where somebody is TRYING to make stuff free. Software is just a description just like your language and words is your way of being able to express yourself. Trying to have some freedom for knowledge and information is very important. At least Debian is trying.
Fourth: Debian is NOT broken. This is simply misinformation.
Fifth: There are other processor architectures beside x86. While I personally think Richard Stallman is a it wacko he does communicate many valid points. You should try to listen to what he says and perhaps he is just a bit less nuts than you think (although he is and probably will continue to be above average nutty)
Sixth: Supporting multiple architectures is very important even if they are not as popular as x86. Why? Simply because it ensures code quality e.g. the code is written correctly and runs on various architectures.

[BaronHK]

First of all, Debian is NOT the problem here. It is the faulty hardware.
Second: Debian allows you to correct the problem by installing non-free software anyway. Just not by default.
Third: You seem to miss the point where somebody is TRYING to make stuff free. Software is just a description just like your language and words is your way of being able to express yourself. Trying to have some freedom for knowledge and information is very important. At least Debian is trying.
Fourth: Debian is NOT broken. This is simply misinformation.
Fifth: There are other processor architectures beside x86. While I personally think Richard Stallman is a it wacko he does communicate many valid points. You should try to listen to what he says and perhaps he is just a bit less nuts than you think (although he is and probably will continue to be above average nutty)
Sixth: Supporting multiple architectures is very important even if they are not as popular as x86. Why? Simply because it ensures code quality e.g. the code is written correctly and runs on various architectures.

Actually, you're still missing the point that the non-free firmware from the BIOS is loaded and running on the CPU no matter what you do with Debian. The only question, again, is whether it is firmware with the bug or without the bug. By not shipping firmware without the bug, Debian is breaking your system, and Debian is broken. It's the job of the OS to ship updated firmware as problems are discovered and fixed. The OS is broken if it doesn't do that.

[dungeon]

By not shipping firmware without the bug, Debian is breaking your system, and Debian is broken.

Debian is not broken since these firmwares are in repos and it just matter if user wanna installing or not, so solution is there but decision is up to you

Of course it is in non-free repo, since any kind of blobs goes there... Now, if you are sure in Intel that this up to date blob is better than earlier and it does not break something else also then do it, otherwise don't

[waxhead]

Actually, you're still missing the point that the non-free firmware from the BIOS is loaded and running on the CPU no matter what you do with Debian. The only question, again, is whether it is firmware with the bug or without the bug. By not shipping firmware without the bug, Debian is breaking your system, and Debian is broken. It's the job of the OS to ship updated firmware as problems are discovered and fixed. The OS is broken if it doesn't do that.

Yeah, message understood. Again, this is NOT a problem with Debian (or any other Distro / OS for that matter). It is important to understand that the hardware is broken by default. It's not the OS.
So now that we have settled that the hardware is the root cause there are options to deal with that. Either the hardware manufacturer issues a recall or you apply either a workaround OR a update to the existing hardware.

BIOS / UEFI and what not should ideally be responsible for the firmware updates. If the OS supplier choose to provide some means to work around the issue it should be considered a "luxury service" and you can't claim that a OS is broken if it does not do that.

This is the same as claiming that Windows is broken because it does not itself provide updated drivers for broken hardware (RAID cards, sound cards etc). You know what? you're argument would possibly have been a tad more valid for Windows since this is a operating system you actually (should) PAY for , however in my point of view it is invalid even for Windows (which are horribly broken in a number of ways anyway). Debian (and most Linux distros) on the other hand cost you ZERO.

And as I mentioned - the firmware update IS available. It is in the non-free repo (which by the way also is free). Ideally that package should end up in the main repos, but what you are basically arguing against is that the file is in the "wrong directory". That is a small price to pay (in fact zero) for a totally free and rock solid operating system.

[chithanh]

OK, so let's say my hardware product is built around one or more FPGAs and the hardware design is loaded into the chip as a binary image at power-on. Does the fact the HW can be changed by loading a new binary file (which is the same as the microcode case) mean that my entire hardware design becomes "software" and must be opened up ?

If not, how is that different from our case where HW is designed as a state machine and behaviour is completed by a microcode image ?

My understanding of the FSF position: If the FPGA is like the one in NVidia G-Sync monitors which is can in principle be updated, but in practice there is no intention/it doesn't happen, then it can be considered hardware. If however the manufacturer ships regular new FPGA/microcode programs and expects users to install them, then yes, that is an unethical piece of proprietary software.

A situation like the one you mention actually exposes the hypocrisy of people who say closed source firmware is ok, but closed source kernel drivers are not: The Atheros HAL for the madwifi driver, which was rejected by Linux kernel folks. If someone made a piece of hardware which could natively load the HAL module and execute it as firmware, then it would have become acceptable to ship in the kernel according to its own rules.

It is in the non-free repo (which by the way also is free). Ideally that package should end up in the main repos,

I don't think that it should be in the main repo unless it is free software. Maybe Debian could give up being a free distribution by default, and become something like Fedora. But as long as they advertise being free, then such a package has no place in main.

[Jabberwocky]

I'm using ubuntu-desktop 17.04 with latest updates (27 June 2017). My intel-microcode version is 3.20161104.1. I hope it helps to install intel-microcode_3.20170511.1~bpo8+1_amd64.deb from the debian pool. (https://askubuntu.com/a/929333/627738).

I am not sure if these hyper-threading issues (is/was) the cause of my system hangs. My Kaby Lake "Intel(R) Core(TM) i5-7200U CPU" is the cause of a lot of frustration. My syslog and kern.log does not contain any hints besides the \0 chars in my kern.log once in a blue moon. I have ran a memory test for hours without any issues. It really sucks to try and debug and issue if you don't have any information. I'm looking forward to the day that I can replace this laptop.

[Niarbeht]

Heh, good to know that it's not just Ryzen that misbehaves these days.

My 4790k behaved _VERY_ badly when I first started booting my Arch install after upgrading from a Phenom II, until I installed the intel-ucode package. So yes, Intel CPUs have been having issues for a long, long time.