Intel Skylake/Kaby Lake processors: broken hyper-threading [LWN.net]

Intel Skylake/Kaby Lake processors: broken hyper-threading

Posted Jun 27, 2017 8:00 UTC (Tue) by cpanceac (guest, #80967)
Parent article: Intel Skylake/Kaby Lake processors: broken hyper-threading

Is there a way to reproduce this? I'm interested in testing it on another processor(s) where we experience "file not found" in Yocto builds when the file is actually there.

to post comments

Intel Skylake/Kaby Lake processors: broken hyper-threading

Posted Jun 27, 2017 12:14 UTC (Tue) by nix (subscriber, #2304) [Link]

Honestly that doesn't sound like a hyperthreading bug to me, but more like a software problem. A thousand things can cause that symptom from filesystem bugs through networking bugs through obscure dcache bugs through things like the combination of 32-bit code compiled without -D_FILE_OFFSET_BITS=64, filesystems with 64-bit inodes, and code that assumes that stat() failures must be -EEXIST and that e.g. -EOVERFLOW is impossible.

Intel Skylake/Kaby Lake processors: broken hyper-threading

Posted Jun 27, 2017 13:15 UTC (Tue) by chris.sykes (guest, #54374) [Link]

When I've encountered bugs like this in my Yocto builds, they've almost always been due to race conditions exposed by parallel builds.

A favourite is concurrent recipe and recipe-native builds.

Intel Skylake/Kaby Lake processors: broken hyper-threading

Posted Jun 27, 2017 22:34 UTC (Tue) by tialaramex (subscriber, #21167) [Link] (1 responses)

Three things, in order:

1. Human error in your specific case. Like, you wrote "foo.jpg" in one place and "foo.jpeg" in another place and those aren't the same even though in your _head_ they seem like the same. Or you copy-pasted an example you found on Stack Overflow without understanding why the circumstances it was written for differ from yours...

2. Software error: Software is also written by humans, but other humans besides you use it, so they'd be somewhat likely to find bugs first. Statistically you don't see the bugs. But only statistically. Example: the build software has a bug.

3. Hardware error: The computer doesn't actually compute correctly.

Always assume the problem is (1), because this assumption will virtually always prove correct. Your comment suggests you haven't embraced this assumption, which is going to be embarrassing for you over and over until you learn.

Intel Skylake/Kaby Lake processors: broken hyper-threading

Posted Jun 28, 2017 0:35 UTC (Wed) by excors (subscriber, #95769) [Link]

On the other hand, if you state very publicly and with great confidence that you are sure there is a bug in someone else's software/hardware/etc because you've checked extremely carefully and there's no possible way the problem could have been caused by your own code, and especially if you imply they are idiots for making such mistakes, then within a couple of hours (just slightly too late to retract your accusations) you are highly likely to discover the blindingly obvious bug in your own code. The universe seems to have a tendency to maximise embarrassment like that.

If you're willing to put up with the embarrassment, it's a very quick way to get your problems solved.