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

CPU Bugs (2018)

danluu.com

Post reply on HN
Print view View original

11–20 of 21 posts

Re: CPU Bugs (2018)

#11

Post by tlb »

Stratoscope wrote: post #10

The 8088 processor in the first IBM PC had a bug that gave me some grief. (The code below is likely to have bugs of its own - I wrote it from memory as an illustration of the CPU bug - and thanks to 'tlb' for catching an error in my first draft. I also left out the question of what data segment the various MOV instructions use for their memory references, as it isn't relevant to this CPU bug.) If you needed to work i…

Why does the pop at the end of:

  push sp
  mov sp, myPrivateSP
  ...
  pop sp
work? Isn't it popping from the private stack, while it was pushed on the regular stack?

Re: CPU Bugs (2018)

#12

Post by Stratoscope »

tlb wrote: post #11
Stratoscope wrote: post #10

The 8088 processor in the first IBM PC had a bug that gave me some grief. (The code below is likely to have bugs of its own - I wrote it from memory as an illustration of the CPU bug - and thanks to 'tlb' for catching an error in my first draft. I also left out the question of what data segment the various MOV instructions use for their memory references, as it isn't relevant to this CPU bug.) If you needed to work i…

Why does the pop at the end of: push sp mov sp, myPrivateSP ... pop sp work? Isn't it popping from the private stack, while it was pushed on the regular stack?

Oh, good catch! I was doing this from memory, and definitely have a bug there.

Updated now, hopefully this will be a more plausible example. Let me know if you spot something else! :-)

Re: CPU Bugs (2018)

#13

Post by hulitu »

Flow wrote: post #9
anonymousiam wrote: post #6

"As someone who worked in an Intel Validation group for SOCs until mid-2014 or so I can tell you, yes, you will see more CPU bugs from Intel than you have in the past from the post-FDIV-bug era until recently." A most prescient remark in 2014. Here's where they are more recently: https://www.zdnet.com/article/intel-fixed-236-bugs-in-2019-a... https://www.techradar.com/news/latest-intel-cpus-have-imposs...

When this news broke I though Intel lost their mind. Did they really intend to just "skip" validation or did they try to automate it further, to decrease time to produce a new chip?

Testing is expensive. That's why it has a great potential for savings.

Re: CPU Bugs (2018)

#14

Post by mrslave »

bombcar wrote: post #8
jeffbee wrote: post #5

Earlier quoted context omitted.

The updates are often fatal, though. These include things like the Opteron "Barcelona" TLB bug and the first-generation EPYC "Naples" frequency scaling bug. The fix for the former knocked 20% off the performance of that generation of parts, and the fix for the latter meant that you had to run at the base clock frequency at all times, getting neither turbo boosts nor power savings. If you apply all of the speculative…

Yeah, I was thinking more of architecture errors where the solution is “modify the compiler so that code isn’t called” - though some may allow microcode updates. The various spec-ex workarounds actually matter more on things like cloud servers than they do on dedicated/controlled hardware.

When microcode is so small (2K according [0]) how can it work to enable/disable specific instructions, or even change how they work?

[0] https://en.wikipedia.org/wiki/Intel_Microcode

Re: CPU Bugs (2018)

#15

Post by amelius »

userbinator wrote: post #2

It's funny to hear that the bug increases are an effect of Intel trying to compete with ARM SoCs in mobile devices, because the errata those have are much worse --- and indeed a lot of embedded stuff is like that because the general line of thought there is that bugs are worked around in software and there's little expectation of being able to run existing code flawlessly, unlike with a PC.

> the general line of thought there is that bugs are worked around in software and there's little expectation of being able to run existing code flawlessly, unlike with a PC.

How does that work for Apple's M1?

Re: CPU Bugs (2018)

#16

Post by amelius »

bombcar wrote: post #3
userbinator wrote: post #2

It's funny to hear that the bug increases are an effect of Intel trying to compete with ARM SoCs in mobile devices, because the errata those have are much worse --- and indeed a lot of embedded stuff is like that because the general line of thought there is that bugs are worked around in software and there's little expectation of being able to run existing code flawlessly, unlike with a PC.

Nowadays there’s hardly a device that can’t easily be updated after shipment - so the cost and effort required to make a perfect error-free CPU is not as incentivezed.

> Nowadays there’s hardly a device that can’t easily be updated after shipment - so the cost and effort required to make a perfect error-free CPU is not as incentivezed.

This ignores the fact that there can be security exploits.

Re: CPU Bugs (2018)

#17

Post by saagarjha »

amelius wrote: post #15
userbinator wrote: post #2

It's funny to hear that the bug increases are an effect of Intel trying to compete with ARM SoCs in mobile devices, because the errata those have are much worse --- and indeed a lot of embedded stuff is like that because the general line of thought there is that bugs are worked around in software and there's little expectation of being able to run existing code flawlessly, unlike with a PC.

> the general line of thought there is that bugs are worked around in software and there's little expectation of being able to run existing code flawlessly, unlike with a PC. How does that work for Apple's M1?

https://github.com/apple/darwin-xnu/blob/8f02f2a044b9bb1ad95...

Re: CPU Bugs (2018)

#18

Post by Liquid_Fire »

mrslave wrote: post #14
bombcar wrote: post #8

Earlier quoted context omitted.

Yeah, I was thinking more of architecture errors where the solution is “modify the compiler so that code isn’t called” - though some may allow microcode updates. The various spec-ex workarounds actually matter more on things like cloud servers than they do on dedicated/controlled hardware.

When microcode is so small (2K according [0]) how can it work to enable/disable specific instructions, or even change how they work? [0] https://en.wikipedia.org/wiki/Intel_Microcode

If I'm reading that page right, the update is 2 kB but it does not contain a full set of microcode, only some sort of patch e.g. only for the instructions that need fixes.

Re: CPU Bugs (2018)

#19

Post by Flow »

hulitu wrote: post #13
Flow wrote: post #9

Earlier quoted context omitted.

When this news broke I though Intel lost their mind. Did they really intend to just "skip" validation or did they try to automate it further, to decrease time to produce a new chip?

Testing is expensive. That's why it has a great potential for savings.

I think Intel was more concerned about the time it took to make a new CPU rather than the cost. At least that was my impression of it at the time.

That testing is a cost is a given. But it's a known cost compared to what a huge batch of faulty CPU's can cost. Or how about a ruined reputation, how do you even know what that could cost you?

I suppose Intel already use a lot of automated testing, but given all the bugs since the change it seems it is not enough.

Re: CPU Bugs (2018)

#20

Post by mrslave »

Liquid_Fire wrote: post #18
mrslave wrote: post #14

Earlier quoted context omitted.

When microcode is so small (2K according [0]) how can it work to enable/disable specific instructions, or even change how they work? [0] https://en.wikipedia.org/wiki/Intel_Microcode

If I'm reading that page right, the update is 2 kB but it does not contain a full set of microcode, only some sort of patch e.g. only for the instructions that need fixes.

Interesting. So a CPU at version N is updated by a sequence of N patches applied in order, where each patch is a pair of location and code-as-data, plus noise (gotta confuse the competition, and hackers I guess).
Post reply on HN