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

Intel Skylake/Kaby Lake processors: broken hyper-threading

lists.debian.org

Post reply on HN
Print view View original

131–140 of 278 posts

Re: Intel Skylake/Kaby Lake processors: broken hyper-threading

#131

Post by ComputerGuru »

lorenzhs wrote: post #33
wyager wrote: post #29

Earlier quoted context omitted.

This seems like precisely the sort of thing that a competent manufacturer should rule out formally. Formal verification of individual FUs isn't exactly ambitious... I think we're getting to levels of complexity where the process Intel uses, with lots of different QA and testing teams doing their best to look for bugs, just isn't going to cut it. We need formally verified models transformed step-by-verified-step all t…

So it's okay for software to have bugs that get fixed (I think everybody here acknowledges that software will always have bugs), but Intel isn't allowed to have issues in their processors, even if they can fix them with a software (microcode) update?

If this "fix" ends up disabling HT, how can I get a refund not just for the CPU but for the $3k laptop I spec'd around it? Without needing to sue?

Re: Intel Skylake/Kaby Lake processors: broken hyper-threading

#132

Post by baruch »

davidmr wrote: post #65
wbl wrote: post #18

Earlier quoted context omitted.

CPU manufacturers do do huge amounts of testing, and Intel does formal verification of some functional units. The reliability is far better than most software, in part because making a new release costs billions.

In my limited experience, their root cause analyses are really impressive as well with lots of internal attention and resources. I'm not allowed to talk about any Intel issues, but we reported a very strange issue to Nvidia, sent a couple of dozen cards back and six months later got a truly fascinating report back we with hundreds of pages of compute test result tables and electron microscope images and chemistry lab…

I worked for a large company that used thousands of Intel CPUs every year and when we suspected a CPU bug we were mostly brushed off. We had a very persistent person on the team who kept tracking the issue to find correlations and some very good kernel developers that went on to nearly pin-point the issue and only then did Intel pay attention and it then took them still several months to acknowledge the issue give a brief report on the issue and acknowledge that our proposed workaround will indeed work.

I've never seen Intel do a very good job at failure analysis or following on with failures unless prodded very hard.

Re: Intel Skylake/Kaby Lake processors: broken hyper-threading

#133

Post by ncr100 »

d33 wrote: post #40
theGimp wrote: post #24

The issue was being investigated by the OCaml community since 2017-01-06, with reports of malfunctions going at least as far back as Q2 2016. It was narrowed down to Skylake with hyper-threading, which is a strong indicative of a processor defect. Intel was contacted about it, but did not provide further feedback as far as we know. Fast-forward a few months, and Mark Shinwell noticed the mention of a possible fix for…

What exactly do you find inexcusable here?

It was reported to Intel who fixed it and did not reply to the reporter.

Re: Intel Skylake/Kaby Lake processors: broken hyper-threading

#134

Post by ComputerGuru »

So, serious question: If the microcode "fix" for this ends up disabling HT, how does one get a refund not just for the CPU but for the $3k laptop I spec'd around it? Without needing to sue?

This isn't a hypothetical; what did Intel do when the only fix for broken functionality was to disable TSX entirely?

Re: Intel Skylake/Kaby Lake processors: broken hyper-threading

#135

Post by laydn »

wyager wrote: post #29
wbl wrote: post #18

Earlier quoted context omitted.

CPU manufacturers do do huge amounts of testing, and Intel does formal verification of some functional units. The reliability is far better than most software, in part because making a new release costs billions.

This seems like precisely the sort of thing that a competent manufacturer should rule out formally. Formal verification of individual FUs isn't exactly ambitious... I think we're getting to levels of complexity where the process Intel uses, with lots of different QA and testing teams doing their best to look for bugs, just isn't going to cut it. We need formally verified models transformed step-by-verified-step all t…

I've done formal verification on several units of a microprocessor, and I can assure you, formal verification on individual FUs is very, very ambitious (think impossible) for a modern microprocessor.

For example, you can not possibly formally verify the fetcher unit on its own, because the state space that you need to cover for several cycles for all the module inputs and outputs is beyond the capability of any formal verification tool.

Typically, you run formal verification on sub-blocks of sub-blocks of FUs.

For this particular bug, it looks like multiple functional units are involved, so it might have been missed by formal verification.

Re: Intel Skylake/Kaby Lake processors: broken hyper-threading

#136

Post by CalChris »

valarauca1 wrote: post #123
cesarb wrote: post #75

Earlier quoted context omitted.

> short loops of less than 64 instructions that use AH, BH, CH or DH registers as well as their corresponding wider register (e.g. RAX, EAX or AX for AH) This is yet another of the many places where the complexity of the x86 ISA shows up and makes its hardware implementations more complicated: the x86 ISA has instructions which can modify the second -lowest byte of a register, while keeping the rest of the rest of th…

You really don't know what you're talking about. --- For Skylake, they probably optimized partial register writes to these four partial "high" registers (AH, BH, CH, DH), but the optimization was buggy in some hard-to- hit corner case. They did not do this. The high registers (AH/BH/DH/CH) are nearly written out of existence with the REX Prefix in 64bit mode. Within the manual(s) it is called out effectively not to u…

> The high registers (AH/BH/DH/CH) are nearly written out of existence with the RAX flag in 64bit mode. Within the manual(s) it is called out effectively not to use them as they're now emulated and not support directly in hardware.

I think you meant REX prefix but even that doesn't make any sense.

High registers are a first class element of the Intel 64 and IA-32 architectures. They aren't going anywhere. Microarchitectural implementations are an entirely different thing.

That aside, where in the manuals does Intel say not to use the high registers? They're pretty clear about such warnings and usually state them in Assembly/Compiler Coding Rules.

From the parent:

> For Skylake, they probably optimized partial register writes to these four partial "high" registers (AH, BH, CH, DH), but the optimization was buggy in some hard-to-hit corner case.

That is about right. I don't agree with the preceding slap at x86 but this is a good summary.

BTW writing to the low registers is in principle also a partial register hazard but then Intel sees fit to optimize that as a more common case.

In particular, mov AH,BH is not emulated from the MS-ROM which is just hella slow. It uses two μops for Sandy Bridge and above. This is covered in 3.5.2.4 Partial Register Stalls.

Lastly, there is no section 3.4.1.7 in the Intel® 64 and IA-32 Architectures Software Developer’s Manual which is 3 volumes. You must be talking about the Intel® 64 and IA-32 Architectures Optimization Reference Manual which is a single volume. And it isn't clear how that section furthers your argument.

Re: Intel Skylake/Kaby Lake processors: broken hyper-threading

#137

Post by my123 »

pvdebbe wrote: post #86
Nexxxeh wrote: post #22

Earlier quoted context omitted.

By my reading, it's fixed in Micro-code, so if you Windows Update, you already have it fixed.

I wonder if one could update the microcode using a ring 0 virtualization platform and Windows as a guest.

Nope, can only be done in the host and not VMs for security reasons.

Re: Intel Skylake/Kaby Lake processors: broken hyper-threading

#138

Post by sclangdon »

pedrocr wrote: post #129
isatty wrote: post #89

Earlier quoted context omitted.

I'm on a Kaby Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz I haven't seen any erratic crashes yet on code compiled by LLVM 8.1.0 on multiple projects (ROS, Qt5). I hope a microcode fix is pushed by Apple on behalf of Intel soon.

Are you from the future? Isn't LLVM currently at 4.0 and going for 5.0 soon?

macOS comes with Apple's build of Clang, which has different versioning from "proper" Clang.

Re: Intel Skylake/Kaby Lake processors: broken hyper-threading

#139

Post by isatty »

pedrocr wrote: post #129
isatty wrote: post #89

Earlier quoted context omitted.

I'm on a Kaby Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz I haven't seen any erratic crashes yet on code compiled by LLVM 8.1.0 on multiple projects (ROS, Qt5). I hope a microcode fix is pushed by Apple on behalf of Intel soon.

Are you from the future? Isn't LLVM currently at 4.0 and going for 5.0 soon?

It prefixes the version with Apple LLVM so I assume it is versioned differently.

Re: Intel Skylake/Kaby Lake processors: broken hyper-threading

#140

Post by mixmastamyk »

ComputerGuru wrote: post #134

So, serious question: If the microcode "fix" for this ends up disabling HT, how does one get a refund not just for the CPU but for the $3k laptop I spec'd around it? Without needing to sue? This isn't a hypothetical; what did Intel do when the only fix for broken functionality was to disable TSX entirely?

I remember the pentium bug in the mid 90s, they actually shipped out replacement processors. Doubt that could be pulled off on laptops. Perhaps a microcode update can work around it.
Post reply on HN