Intel seems really interested in pushing bad quality parts to their customers, are the Managers short on Intel?
During April and May, Intel started updating its processor documentation with a new errata note – and over the weekend we learned why: the Skylake and Kaby Lake silicon has a hyper-threading bug. The erratum is described in detail on a Debian mailing list, and affects Skylake and Kaby Lake Intel Core processors (in desktop, …
I remember (many, many moons ago, when I worked at a certain cellular base-station manuacturer that used a stylised bat-wing for a logo) having an arguement with the technical architect about the use of non-Intel processors (AMD had just bought out the K6 and I was quite keen on them).
His answer was to specify that non-Intel processors should never be used "because you knew what you got with Intel and their processors were bug-free".
The next day Intel revealed the news about the FooF microcode bug.
Oh, how we laughed.
I can't access the computer unless/until the ScreenReaderEnvironment (SRE) starts talking, & there's no pre-OS-SRE, meaning I can't boot the computer to a SRE in order to get into the BIOS to update this kind of crap even if they DID release a fix that was SRE accessible.
I'll have to pay a Sighted Techie to do this for me, and that means heading to someplace like BestBuy.
I *really* don't want anyone at BestBuy touching my computer, I don't trust them as far as I could comfortably shoot one out my arse. =-(
*HeadDesks in frustration*
You're going to have a long wait if you want OS X or Linux executables to patch your UEFI.
For Apple Mac users that's just another patch to run (see this as an older example. Firmware BIOS or UEFI upgrades are generally not hard to do, but they're rare. Other than with Apple where it simply shows up as an update that needs a reboot to complete, few users realise they need it because it's not really part of the Microsoft or Linux update cycle - it's hardware.
Unless users are in touch with whoever manufactured their hardware, how will they find out? I guess it's easier with Microsoft sourced hardware where the associated subscription will at least provide a point of contact.
For Linux, you just need the package intel-microcode.
You get it with 'sudo apt-get install intel-microcode', or graphically with the dialog box for additional (aka proprietary) drivers. You would use the same dialog box, for example to get the nVidia proprietary drivers instead of Nouveau which is the Open Source implementation for nVidia GPUs.
Here is what the documentation of the intel-microcode package says:
This package contains updated system processor microcode for Intel i686 and Intel X86-64 processors. Intel releases microcode updates to correct processor behavior as documented in the
respective processor specification updates.
So you just need to wait that you distro updates this proprietary stuff.
intel-microcode might help in this limited circumstance (assuming it handles suspend properly) but what about other issues that require UEFI patching, like the recent ME exploit? That can't be fixed through the Linux kernel since it operated below the level of the OS or even a hypervisor. Any laptop that doesn't let you patch UEFI directly that is running Linux needs a Windows partition - that's the only reason I have one on mine.
If you could fix the issue if Screen Reader were working then I am sure you could find someone willing to act as one while you accessed your BIOS.
While sympathising with your predicament it surely isn't the first time you have ended up needing reading assistance which technology doesn't cater for.
I stand corrected on OS X UEFI updates. I hadn't ever seen them on Intel's site, but it makes sense Apple would distribute them directly.
You still can't get Linux executables to patch UEFI, if your UEFI doesn't patch itself directly like my laptop's doesn't, you have to keep a Windows partition around just for that purpose.
did... you seriously just tell a blind person that you're "sure" they can "find someone" to just be a screen reader?
if you *really* do sympathise with the difficulties that come with being disabled, then please, heed my advice: comments like the one you just left aren't helpful, and in fact, they are patently unhelpful.
this person quite obviously knows their living situation and everything associated with it. if there was someone who lived locally enough that would help, that the person trusted, that they would do that? instead, they said their *only* option would be taking it to a store, which they didn't trust with their computer.
which goes to say that if there were a generic Someone they could ask "to be a screen reader", they probably wouldn't trust that they were only doing what was asked of them too.
let alone, like... i'm guessing since you post on this site you've had the "joy" of doing tech support for uninitiated family members over the phone? ones who describe what's on screen in such a bizarre way that you have *no* idea what's going on? that's almost certainly what it would be like for this person with a generic Someone, even if such a person were available.
now, i'm going to assume good faith here, and bring up that: a lot of disabled people (or people with disabilities, depending on what the OP to this chain prefers [people do often prefer one or the other, i usually go with "disabled" for myself rather than "person with disabilities"]) do live independently enough that family and friends don't live anywhere near close enough to just come round and offer support like this on a whim.
i bring this up because it's still very prevalent in our popular culture the idea that disabled people always have family, or a romantic partner, or some kind of hired carer, available at all times. which is simply not the case for a lot of people (even though there are people who need such 24/7 help) and as such, is generally pretty patronising to say something like what you said, that you're "sure [they] could find someone". why? *what* makes you sure? please take some time to think about that.
disclaimer: i am sighted, but disabled in other ways. i do not presume to have all the answers of how to speak to blind/Blind people specifically. rather, i am just painfully aware of how people with all kinds of disabilities get given "advice" like "get a friend or neighbour to help you with it", as if it should be normal for someone to just need the charity of an abled person to do something everyone else can do independently.
I think the most important point you missed is that disabled people* generally don't want to have to depend on other people. Independence is something very powerful and precious to them.
*Not sure what the correct phrase or terminology is here, sorry. No offense intended.
Facetime with a sighted friend who will read the screen to you.
There's an iPhone app that senses light, so you can even tell when the screen lights up.
(Equivalent tools are no doubt available on Android and Windows Phone. It's just that all my blind friends use iPhones.)
Well, have you seen those symptoms yet? If not...
Also, look at how long it took them to find this, since it affects all Skylakes it is at least two years since customer testing of Skylakes started, even longer since Intel did internal tests. It can't be all that common or easy to trigger, or it would have been identified a LONG time ago.
Well, on the other hand, how many people actually bother (or are able) to root-cause random crashes to the Point where the microcode can be properly blamed?
Even if it's a perfectly repeatable crash most people would blame it on application/OS bugs and work around it.
I'd think that the only people who actually HAVE to hunt down bugs like this would be compiler authors and related fields.
Not necessarily. Guys who run performance benchmarks at Tom's Hardware Guide once noticed that newest Intel Pentium III 1333MHz (or was it 1133MHz?) consistently crashed at Linux kernel compilation test.
Found it on Wikipedia: "A 1.13 GHz version was released in mid-2000 but famously recalled after a collaboration between HardOCP and Tom's Hardware discovered various instabilities with the operation of the new CPU speed grade."
"When I was testing the Pentium III 1.13 GHz I was also using a GNU/Linux installation to run kernel compilation benchmarks. I had introduced this benchmark in our processor-benchmarking suite only recently and was therefore not too experienced with this operating system. What I knew for sure however was that my Pentium III 1.13 GHz hadn't been able to finish the compilation even once."
I agree fully. Looking at the timeline in the Debian message, this has been ongoing for some time. So incidence and significance seem favourable.
And as for some comments here:
The latest Dell boxen we have here allow BIOS flash/updates OS independently, because there is the f12 option way before any OS has booted. Just get the update package at Dell and use the update option under F12 during boot. Whether Dell already adapted/ upgraded their BIOS, that is another question of course (quick check for our boxen resulted in a firm no).
As for Linux - not uncommon, the Linux updates are also coming through with a significant delay. For example, where Debian (from stretch upwards) already have the new intel-microcode, ubuntu still haven't pushed this newer version (for their LTS) yet.
Then again, as WUSP show, careful review and deployment of updates is always a good thing...
I have had some unexplained major performance issues with a heavily multi-threaded application on a Kaby Lake i7 that do not occur on my Haswell i7 development machine. At times the 3.6GHz Kaby Lake significantly under-performs the 2.2GHz Haswell. I kind of doubt this microcode issue is the cause, it's much more likely to be a bug in my code, but I have been racking my brains and not found the cause yet, so I'm going to disable HT and see what happens.
> "or it would have been identified a LONG time ago."
It may well have been found a long time ago. Trouble is, intel have a habit of sitting on information like this so as not to harm their channel partners (who would have to dump stock), and themselves who may have to issue a huge buyback.
Better to wait and bury the head in the sand while the engineers can figure out if it can be fixed in the field.
I have a laptop given to me by IT sitting in the corner. As anything handed out by corporate IT it is an Intel. To be more exact Hell with Skylake. I do not recall a "hyperthreading off" toggle in the BIOS though...
I had to put it on extended leave because it was showing some seriously weird behavior with Java coredumping. I suspect it is the same bug. Based on its behavior I would say - every couple of hours under heavy load.
>Anyone know how likely this is to occur?
Agree, if I understand the problem correctly, it should be causing user visible random system glitches and instability. Thus given the number of PC's running Windows it is correct to ask why we aren't seeing a lot of feedback about random Windows faults etc.
Additionally, whilst I don't know the extent to which the OCaml compiler is used, we should also be questioning whether there something the OCaml compiler is doing (with respect to hyper-threading) that Windows and other compilers aren't doing.
Current Linux distros (Ubuntu from at least 15.04 on) have a "3rd party driver" feature to update the CPU microcode. Both, for AMD and Intel.
Does this solve the problem? If so, enabling that driver would be a simple workaround.
I wonder, if a similar feature is available for Windows, too.
Edit: See also:
Hmm, a short search of the microsoft website shows that there is at least a mechanism for microsoft to update the microcode. They seem to deliver it via windows update.
Perhaps Intel can persuade them to deliver this specific update quickly and with a comprehensive description?
"Current Linux distros (Ubuntu from at least 15.04 on) have a "3rd party driver" feature to update the CPU microcode. Both, for AMD and Intel."
Such mechanisms have existed since the days of oops-I-can't-divide. So why are Debian saying it can't be fixed except by motherboard firmware?
Does current firmware shut the door on such mechanisms? That might be done for security reasons - block malware that attempts to rewrite microcode - but if so there needs to be a better way to fix it than depending on motherboard manufacturers getting round to distributing upgrades, always assuming they can be bothered.
For Skylake, the latest version of the Linux microcode update will fix this.
But for Kaby Lake, Intel have not released the fixed microcode publicly, it's only available to motherboard manufacturers. So you will have to ask your PC or motherboard vendor for an updated BIOS/UEFI that includes the latest microcode.
That's Intel's fault for having a fix and not releasing it to the public, there's not much that Debian can do about it.
Biting the hand that feeds IT © 1998–2019