Re: Not good news for the new iMac...
Don't get all giddy. Apple will deliver these new systems with the microcode already patched, you can be sure of that.
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, …
Don't get all giddy. Apple will deliver these new systems with the microcode already patched, you can be sure of that.
They don't have to. As soon as the user has done first setup it will run the update and pull in the relevant patches since production, update, possibly reboot and that will be that.
Sure, what is produced now (well, in a few days from now) may be supplied pre-patched already, but there's no point in opening up existing stock, that would be silly :). There is also the problem that something new may have shown up by then :)
The Screen is a whole lot better as is the GPU than the 2009 version but you don't seem to care.
And the problem is probably temporary so won't affect many people (who buys iMac's these days eh?).
but you seem to really not like Apple so carry on hating them even though this problem does not lie with apple but Intel.
"So the new £5000 iMac Xeon 2017, is well, the same speed as a 2009 i7 iMac 27''?"
It will have eight cores instead of four, at higher clock speed, so it will be an awful lot faster.
It is also supposed to ship in December 2017, and we might assume that Intel will get its act together and ship a fixed product by then.
It will be great.
The screen is the same as my iMac 5k, so very nice.
My iMac does have some cooling issues.. if I compile for 5 minutes, it will get quite warm and the fam will spin madly, I wonder how much noise/heat issues will de Xeons have.. will they throttle while rendering?
As for rendering, etc.. well, I would rather have a threadripper, much faster and cheaper. But sure not as pretty, and if you like Mac OS...
This can only happen when both logical processors on the same physical processor are active.
Combustion can only happen if air contains oxygen
In about 1981 a computer manufacturer - not Intel - trained me and a colleague (we were in an outside company) to create new microcode for their processor.
Microcode is hard. Components of the CPU are running in parallel, some taking several clock cycles, and the microcode designer must take account of these things.
I am sure modern Intel CPUs are much more complicated than anything from 1981. I hope they have better development tools, including simulators, than we did. But now I wonder if there are bugs or design weaknesses in those tools.
Or, I suppose, it could just be undue timescale pressures on the microcoders.
In 1966 the RCA Spectra 70/45 mainframe had microcode that could be software selected for either IBM 360 compatible mode - or second generation RCA 501 (English Electric KDF8) mode.
The ICL 2903 mini-computer range was programmed at microcode level.
The IBM 370 compatible mainframes like the Fujitsu/ICL Atlas range in the 1980s had microcode that could be loaded from floppy disc. This offered various processing speed upgrades as and when the customer required them - without major disruption.
"Which reminds me that I should probably re-read Tracy Kidder's excellent book on Eclipse MV/8000."
Somewhere in that book is a quote along the lines that at least one person afterwards "went back to the soil" - where things moved more slowly than nanoseconds.
Having taken a break from IT on a farm for similar 1970s reasons - I was then glad to get back into IT "where things move a lot faster than the seasons".
The book's subject of the unofficial "backup" development of something also happened in ICL - IIRC with the comms front-end MCU1. Can't remember why the approved new development failed to meet its deadlines - but a skunkwork based on existing hardware was a success.
The problem occurs only with active hyperthreading, i.e. when the CPU is executing two different instructions in parallel that are *supposed* to use non-interfering components of the processor. Hard to find that with simulators.
The code pattern to trigger this bug is also discouraged by Intel Optimization guides as being slow, so probably only coded very rarely by a compiler. Probably not a high priority on simulation experiments until now.
Or 'We think there's a problem around this, let's discourage people from doing it'.
One of the issues is apparently that Intel test their processors less than they used to. Taking time to make sure they were behaving correctly was costing money and making them look slow...
..for the random blue-screens and freezes that nearly every Windows box seems to experience in our organization once in a while. Issues that have happened to our newer Dells with i5s and i7s and that we've never been fully able to eradicate, despite patching/updating everything possible, swapping memory, hardware, etc.
No excuses or benefit of the doubt though for the utterly awful Windows update process that needs to be taken out back of the barn and shot.
Sorry to ask, but have you followed the proper well-established procedures for troubleshooting bugchecks? Probably not, since you can't even tell if this issue can be related or not.
I mean - you are aware that those letters and numbers on the blue screen are there for a reason, aren't you? (Though for serious debugging you will want a kernel dump as well...)
I happen to have a rather nice* Dell XPS 8920 at work. Last BIOS is from March. There's no option to disable HyperThreading.
So far the only things crashing on me are PulseAudio and bluetoothd, and I have no idea if they crash because of this bug or just because there are bugs that need to be ironed out in drivers or the software.
*It's nice after putting up a good fight when I installed Ubuntu on it. I had to mix and match many Internet forum posts in order to win the battle.
I'm just schocked Nostradamus has not even vaguely reported this. We all know the Pentium FDIV bug was a big hit in 1520, so why is there not even a teensie-weensie Quatrain about this one? Not even Hoagland has anything on it (as of this writing). Are we looking at a new conspiracy, stemming from like 500 hundred years ago? (That would make it a 2000-Quarterly financial report Head Fake; must be a record :)
So now AMD to sell Ryzen has to attack Intel finding bugs that highly like don't exist...
Everything about this new microcode bug affecting Intel CPUs looks beyond fishy. And AMD needs to sell the awful Ryzen products at any cost to not go bankrupt.
So they come up with these lies to attack Intel trying to tell the world "you see Intel CPUs are not more reliable than ours" ... What a smart masterplan ..uhh! Fact is that AMD lies against Intel and Nvidia always end up being a huge failure. They think everyone buying CPUs and GPUs must be dumb like their so smart marketeers ...
Heck ! AMD sold the Polaris GPUs out of PCI-E specs that fried the motherboard against any safety standard and then they released a software "fix" with their drivers to slow down the Polaris GPUs to avoid the melt down. THAT is AMD , the ones selling unreliable flawed products.
Not a word about AMD in the article. Nothing mentioned about GPUs.
Yet you bring up both topics. And then you add a conspiracy theory about AMD being behind this.
While I understand that this may be simple trolling or fanboy knee-jerk reaction, I still feel compelled to ask: Why did you actually type that flame out?
I've experienced a lot of crashing of a Skylake i7 that is resistant to BIOS, driver and OS updates. My research lead me to several very long intel discussion forums of people experiencing similar crashing and not much help from Intel. So it's nice to see this is finally being acknowledged at least. Unfortunately the Asus m/board I have seems to not always puch a BIOS update when intel publish microcode updates/fixes, so it could still easily be well over a year before I get a fix (if at all). At least I have a potential working solution now (disable hyperthreading), previous suggestions (on the forums) have not worked, e.g. disabling the various CPU power management strategies has been one most discussed.
You can load microcode after boot as well, from your favorite OS. Linux has a tool for it that runs on boot - t Think it's included with Debian but the actual microcode isn't since it's a non-free binary blob.
Windows has it as well and with some luck microcode updates arrive via Windows Update.
Doing it at the BIOS/UEFI level is mostly needed when a bug/missing feature prevents the system from booting at all.
I just did a Mini-STX build with a Pentium G4560 and notice that the system crashes regularly due to the integrated GPU if I don't enable the proprietary microcode. Guess I'm just damned if I do, damned if I don't at this point...
You should ALWAYS update the Microcode, running without any Microcode patches is really really bad.
All processors are designed to have fixes applied as bugs are found, instead of having to "mask out" a new processor DIE each time, or slowing the process of releasing a new processor to 1 per decade.
This is not a design flaw, it reduces costs if they can fix design flaws on the finished product after it is manufactured or even after it ships.
Dozens of major and minor bugs have been fixed in the Microcode update prior to the first processor shipping, so running without these fixes is really really really bad.
When a bug is found during the extensive testing phase, a Microcode fix is designed to resolve that problem. And while we could complain about this not being found earlier, it is usually the support community that finds these obscure hard-to-find bugs that feedback into the CPU company for fixes.
Consider it the same as never updating a software package, even though known bugs are in it, without uninstalling the original software package and downloading and installing a whole new version.
You would be asking why the software company didn't just release a patch to fix it.
Why wait for a bios update or perhaps a microcode update via windows update?
With this VMWare thingy you can grab the latest microcode files from Intel (and AMD, otherwise the program may not work - not tested). This is installed as a driver, and in the event log you can see if a microcode update has been applied.
Use these microcode files:
Also works great for stuff with no bios update available.
AMD Processors have Microcode Updates released regularly as well.
In fact, when I was designing AMD systems based on bleeding edge chips, like Ryzen, there might be two or three DOZEN Microcode updates after the CPU was released, and perhaps dozens to hundreds of patches already in the Microcode update.
Every time we released a BIOS update for our AMD systems, we would get the latest Microcode update from AMD.
All CPU manufacturers have Microcode updates and issues like Intel just had.
Don't use this as a justification of the difference between Intel and AMD.
I use the fact that AMD "Invents" technology, Intel "evolves" technology.
The first brings us new cool stuff at much lower costs, which the second is safe and profitable.
If Intel was smart, they would use AMD as an R&D house and use Intel's manufacturing capability to build them.
I am working with Intel Support related to a bug I was able to reproduce repeatedly.
They suggested changing Graphics Settings in the game that exhibits the problem.
While this did help, eventually lock-ups and even a corrupted settings file began happening.
Turning off "Turbo-Boost" appears to solve the problem
Reading this article, I have now turned Turbo-Boost back on and turning off Hyper-Threading instead to see if this solves the problem as well.
Since turning off Turbo-Boost seems to fix the problem, I am wondering if that is a better solution than turning off Hyper-Threading.
According to the conditions that "should exist" for boosting to happen, it seems pretty rare that boosting "should" actually happen and losing half my processor threads seems like a bigger performance hit.
Thoughts? (please not rants)
1) Should turning off Turbo Boost also fix this problem? (doesn't seem like it would, but appears to in my case)
2) Would you rather turn off Turbo Boost or Hyper-Threading to solve this problem?
BIOS UPDATE METHODS
If you download the Intel BIOS File onto a USB Flash Key, then:
1) You can update the BIOS in the built-in BIOS Setup utility by surfing to the Device and Directory the BIOS image file is in.
2) Can do a "BIOS Recovery" by holding down the power buttom from the Off state for around 8 seconds (no longer, a LED color change usually signals the recovery) but the ONLY file that can be on the USB Flash key can be the BIOS Image file
3) Use the motherboard vendors BIOS Update utility
So for Linux users, there should be at least 2 update methods available without getting someone else to help you. But it is possible that the BIOS vendor or modifications specified by the motherboard vendor do not support these options.
Biting the hand that feeds IT © 1998–2019