Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Serious Intel CPU bugs (2016)

danluu.com

Post reply on HN
Print view View original

41–50 of 110 posts

Re: Serious Intel CPU bugs (2016)

#41

Post by Valmar »

aristidb wrote: post #26
MulliMulli wrote: post #24

Earlier quoted context omitted.

What bugs?

The article spends 4 paragraphs on them. Just one example: Although AMD’s response in the forum was that these were isolated issues, phoronix was able to reproduce crashes by running a stress test that consists of compiling a number of open source programs. They report they were able to get 53 segfaults with one hour of attempted compilation.

This is only true with Ryzen CPUs that were manufactured before week 25. ThreadRipper wasn't affected, nor was EPYC.

Re: Serious Intel CPU bugs (2016)

#42

Post by TrickyRick »

soziawa wrote: post #28
TrickyRick wrote: post #21

Earlier quoted context omitted.

Good luck explaining to a random vendor what the problem is though. They also need to verify that the problem exists and most of them won't have a clue what you're talking about, they'll just turn the computer on and notice that it's working. If you're a company buying from more qualified vendors then it might be a different story, however at that point consumer law does not apply to you.

Well depending on how this is turning out there will be benchmarks that show the chips performing slower than before. I've read that many chips will be getting 17% slower in the best case and up to 30% in the worst case. That could be enough to warrant a return of the product.

Yes, however most computers are marketed using GHz numbers, not experienced performance (And in the cases where they are it's relative, like x times faster than before). It's hard to show a 17% slowdown to a store clerk.

Don't get me wrong, I'm all for being able to return a product that's 17% slower today than yesterday, I'm just saying it might be difficult since it's an issue that requires a degree of technical knowledge to understand which most store clerks don't have.

Re: Serious Intel CPU bugs (2016)

#43

Post by dspillett »

bwang29 wrote: post #3

Quote from article "We need to move faster. Validation at Intel is taking much longer than it does for our competition. We need to do whatever we can to reduce those times… we can’t live forever in the shadow of the early 90’s FDIV bug, we need to move on. Our competition is moving much faster than we are". Competition pressure could make a company's new product worse than (in this case, less stable than) their previ…

> "we can’t live forever in the shadow of the early 90’s FDIV bug"

There is a valid point there though - if you are testing for testing's sake and not finding anything extra through the extra effort then you are wasting time and potentially worse: lulling yourself into a false sense of security. Testing should be done for utility, not just in response to fear - you need to test intelligently, not just test lots. Like TTD in software, good testing processes make life much easier and quality much higher, bad testing processes can be worse than useless.

Processor bugs are always a thing and always have been a thing - look at the list of bugs the linux kernel scans for and works around many of which pre-date the FDIV debacle.

What made FDIV special isn't that is was a bad bug, it was the recent change in marketing. Before then processors were sold to manufacturers who might tell the customer what is used, unless you were a hobbyist you didn't much care for the specifics. But the Pentium line was the first time a processor had been particularly marketed directly at the end user. It had started with the 486 lines a couple of years earlier when "Intel Inside" was first a thing, but there was a huge push in that direction with the release of the first Pentium lines. Suddenly Joe Public was more aware of that detail, but was blissfully unaware that CPUs are complex beasts and generally not 100% perfect.

It didn't help that the bug was very easy to demonstrate in common applications like Excel so Joseph & Josephine Public could see and understand the problem where they wouldn't, for example, the FOOF bug, and it was easy to joke about (We are Pentium of Borg. Division is futile. You will be approximated) which fanned the rapid spread of the news. The fact that the bug only significantly affected fairly rare combinations was lost in the mass discussion about how such a bug could happen at all.

Re: Serious Intel CPU bugs (2016)

#44

Post by sqldba »

p0nce wrote: post #37
friedButter wrote: post #6

Earlier quoted context omitted.

> Competition pressure could make a company's new product worse than (in this case, less stable than) their previous products Well, that depends on the specific attributes on which there is competitive pressure. When its on time to market, yes, quality will suffer. When its on quality, products will be slower\more expensive,etc. Kind of similar to the often repeated quality triangle in Software dev

> Kind of similar to the often repeated quality triangle in Software dev Which was disproved in practice.

Can you back this up? I googled and didn’t find anything relevant.

Re: Serious Intel CPU bugs (2016)

#45

Post by blattimwind »

mehrdadn wrote: post #15
ta_wh wrote: post #11

Earlier quoted context omitted.

See the three-year warranty here for boxed CPUs: https://www.intel.com/content/dam/support/us/en/documents/pr... Note the first bullet under "WHAT THIS LIMITED WARRANTY DOES NOT COVER": "design defects or errors in the Product (Errata). Contact Intel for information on characterized errata." Guess we're not covered on this one. EDIT: That being said, given the potential scope of this issue (years of affected CPUs, ma…

Thanks for posting this! It seems self-contradictory to me. How can Intel warrant that > the Product will substantially conform to Intel’s publicly available specifications while simultaneously disclaiming warranty for > design defects or errors in the Product (Errata) ? If an instruction does something different than what their specs say on occasion, do they take that to mean it's substantially conforming to their s…

Easy: Erratas are actually specification updates. (And indeed, not just by sound and smoke, since most errata are never fixed but rather declared this-is-how-it-works-now).

In some abstract, philosophical sense it means that the specs are actually elected by majority of the produced processors.

Re: Serious Intel CPU bugs (2016)

#46

Post by blattimwind »

mehrdadn wrote: post #33
ta_wh wrote: post #18

Earlier quoted context omitted.

I'm no lawyer, but my instincts tell me someone would have to prove that the chips today do not conform to Intel's specs, and that this difference is such that the CPU no longer "substantially conforms" to the spec. > If an instruction does something different than what their specs say on occasion, do they take that to mean it's substantially conforming to their specs? We're on the same page. What do you think Intel…

I mean they would likely argue it's still substantially conforming even if it has bugs that come up, but I'm trying to figure out what kind of a case they could actually win.

Why try to win a case if all you need is a settlement? Going into an actual trial is far riskier than negotiating a settlement, for both sides.

Re: Serious Intel CPU bugs (2016)

#48

Post by m_eiman »

mehrdadn wrote: post #31
m_eiman wrote: post #25

Earlier quoted context omitted.

What they're saying is that they'll replace your chip if it behaves differently from all the other chips of the same model, not if ALL the chips are broken by design.

Where does their sentence about the specification come into play in your interpretation?

"the Product will substantially conform to Intel’s publicly available specifications"

They're saying that it should work as specified for the most part. And apparently the CPUs do, since they've been in continuous use for many years.

Note that they also have this exception:

"… THIS LIMITED WARRANTY DOES NOT COVER: … that the Product will protect against all possible security threats, including intentional misconduct by third parties;"

Which is likely designed to handle issues just like this one.

Re: Serious Intel CPU bugs (2016)

#49

Post by dannyw »

dataflow wrote: post #4

Out of curiosity, if you notice a CPU bug in a computer under warranty, is there anything the vendor is usually obligated do, or are they under no obligation to do anything about a CPU bug? Is that considered a defect they have to handle? (Edit: I'm assuming the USA, and I'm assuming bugs that were not known to the vendor at the time of the sale.)

Under Australian law, it depends on if the defect is material, and if it would have reasonably changed your buying decision.

A 30% performance reduction (like the page table isolation fixes) probably would be considered material.

Re: Serious Intel CPU bugs (2016)

#50

Post by kasabali »

adtac wrote: post #17
lukax wrote: post #12

Is this article from 2015 or 2017? It would be great if the page displayed the date that the article was posted/updated. It is not in the URL nor the sources. The only way to see the dates is in the RSS feed and even that is only for new articles.

Jan 2016, according to https://danluu.com/ and ctrl+f

Last update is aug 2017 or later
Post reply on HN