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

141–150 of 278 posts

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

#141

Post by decisiveness »

decisiveness wrote: post #61
onli wrote: post #14

Rule of thumb: On a desktop, if you have an i5 you do not have Hyperthreading. All i3s and i7s do have Hyperthreading, as do new Kaby Lake Pentiums (G4560, 4600, 4620). On laptops, some i5s are not real quad cores but dual cores with Hyperthreading.

>Rule of thumb: On a desktop, if you have an i5 you do not have Hyperthreading. All i3s and i7s do have Hyperthreading, as do new Kaby Lake Pentiums (G4560, 4600, 4620). Hmm...either this statement is wrong or this desktop /proc/cpinfo is wrong: $ grep -E 'model|stepping|cpu cores' /proc/cpuinfo | sort -u cpu cores : 4 model : 94 model name : Intel(R) Core(TM) i5-6600 CPU @ 3.30GHz stepping : 3 $ grep -q '^flags.*[[:…

To quote the Intel Developer Instructions[1] on the HTT flag:

>A value of 0 for HTT indicates there is only a single logical processor in the package and software should assume only a single APIC ID is reserved. A value of 1 for HTT indicates the value in CPUID.1.EBX[23:16] (the Maximum number of addressable IDs for logical processors in this package) is valid for the package.

UPDATE: It appears these flags refer to each initial APIC ID, so it seems the HTT flag value should be 0 in all cases where the overall processor:thread ratio is 1, suggesting there might either be incorrect information in the CPUID instruction for some Intel CPUs or the kernel is not correctly evaluating CPUID.1.EBX[23:16].

Hopefully, someone more versed in CPUs can correct me here.

[1]https://www.intel.com/content/www/us/en/architecture-and-tec...

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

#142

Post by pedrocr »

sclangdon wrote: post #138
pedrocr wrote: post #129

Earlier quoted context omitted.

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.

That's going to be mess when LLVM proper catches up to those version numbers...

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

#143

Post by lvh »

aeleos wrote: post #74
lorenzhs wrote: post #39

Earlier quoted context omitted.

They forgot to follow up on a support ticket. As your quotation mentions, the issue was documented and fixed. Calling that "inexcusable" is a bit strong, don't you think? I'm not a particularly big fan of Intel's practices, but the reactions in this thread seem a bit too strong to me.

It wouldn't be a big deal if this was just software, but the fact that Intel allowed a PROCESSOR bug to be reported, tested, and fixed without telling anyone that the bug actually exists is honestly horrible. You can't just let CPU bugs under the run since it can throw the stability and reliability of the entire system into question. The people that reported it shouldn't have to dig through Intel microcode updates an…

Do we have any evidence that that's where Intel even learned about the bug?

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

#144

Post by ereyes01 »

userbinator wrote: post #7

The problem description is short and scary: Problem: Under complex micro-architectural conditions, 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) may cause unpredictable system behavior. This can only happen when both logical processors on the same physical processor are active. I wonder how many users have experi…

A few past lives ago, I used to work on the AIX kernel at IBM. I once spent a few weeks poring through trace data trying to investigate a very mysterious cache-aligned memory corruption induced by a memory stress test. Our trace data was quite comprehensive, and is always turned on due to its very low overhead. It was concerning enough (and took me long enough) that it eventually sucked in the rest of my team to aid in the investigation. None of these other guys were noobs- a couple of them had (at the time) built over 20 years of experience in this system, and in diagnosing similar memory corruption bugs beyond any doubt (many were due to errant DMAs from device drivers). I had too, though for much less than 20 years.

After several full days of team-wide debugging, we had no better explanation based on the available evidence than cosmic rays, or a hardware bug. IBM's POWER processor designers worked across the street from us, so we tried to get them to help- first by asking nicely, then by escalating through management channels.

Their reply was more or less: we've run our gamut of hardware tests for years, and your assertion that it's hardware related is vanishingly unlikely... we don't look into hardware bugs unless you can prove to us beyond a doubt it's hardware related. Cache-aligned memory corruption without any other circumstantial evidence isn't enough.

On a crashed test system sitting in the kernel debugger for several weeks now, there would be no more circumstantial evidence beyond the traces. A corruption like this was never seen again, by all accounts.

If we were right and it was evidence of a hardware failure, this is one way such a problem can go undetected. I hope it was something else, or even a cosmic ray, but we'll never know for sure, I guess.

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

#145

Post by DamonHD »

Cerium wrote: post #122
ploxiln wrote: post #73

Earlier quoted context omitted.

That's absolutely true. When it comes to CPU/memory, skilled software engineers always think, "it must be my bug, it always is". So in that super rare case of actually running into a CPU defect, it's a mindfuck, it'll drive you crazy. You'll be looking for the flaw in your algorithm which makes it fail once a week under production load. But you just can't find it, it makes no sense ... (When it comes to drivers for n…

A little anecdote describing one such bug. I didn't find this, another one of my teammates did. The symptom was that a board with a specific microcontroller on it would be working fine, then after a power cycle it might not keep working. A flash dump would show that the reset vector, the first byte of flash on that system, would be all zeroed out. Of course the system would not run anymore, but why did it happen? Aft…

Yes, we have seen similar in AVRs (328p) where the lowest voltage brownout threshold/trip is not enough to prevent the EEPROM and/or Flash from getting corrupted somehow...

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

#146

Post by CountSessine »

gcb0 wrote: post #118
CountSessine wrote: post #115

Earlier quoted context omitted.

But that doesn't mean you necessarily get to keep the affected feature - the only 'work-around' might be to disable it. Consider TSX on Haswell and Broadwell, where Intel had to disable the whole feature because of a bug. And of course there was the 486 FP bug which couldn't be fixed by any kind of microcode update. If Intel had to completely disable hyperthreading in Skylake and Kabylake that would make the premium…

you mean i3 and i7. despite what cpuinfo tells you, no HT in i5. and my previous comment was ironic :)

But if you don't have HT in your i7, you basically have an i5 that you paid more than you needed for.

Or has that changed? At one point, i7 was full-featured, i5 was an i7 with HT disabled, and i3 was i7 with HT intact but smaller caches. Is that different with Skylake/Kabylake?

and my previous comment was ironic :)

Ack - sorry. I must be irony-impaired. That's why I don't post very often. :-)

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

#147

Post by rsynnott »

ourcat wrote: post #11

So will this be affecting most Macbook Pros of the past few years? If so, there's a way to disable hyper-threading, but you need Xcode (Instruments). Open Instruments. Go to Preferences. Choose 'CPU'. Uncheck "Hardware Multi-Threading". Rebooting will reset it.

From one of the 2016 MacBook Pros:

> machdep.cpu.model: 78 > ... > machdep.cpu.stepping: 3 > ... > machdep.cpu.microcode_version: 174

Can't find if 174 is the fixed version or not.

So this is one of the models for which there exists a fix, as per the email.

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

#148

Post by Sharlin »

baruch wrote: post #132
davidmr wrote: post #65

Earlier quoted context omitted.

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…

To be fair, I don't even want to think about the amount of spurious bug reports they are probably receiving.

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

#149

Post by [deleted] »

baruch wrote: post #132
davidmr wrote: post #65

Earlier quoted context omitted.

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…

[deleted]

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

#150

Post by DamonHD »

userbinator wrote: post #76
pshc wrote: post #60

Earlier quoted context omitted.

I wonder if there's a CPU out there that doesn't have bugs.

It depends on how exactly you define a bug, but something like a 6502 or Z80, which has essentially all the errata well-documented since it has existed for so long, might qualify.

Z80 implementations for one had a whole slew of undocumented instructions, allegedly because they were buggy in some way.
Post reply on HN