Live data from Hacker News

Intel Skylake/Kaby Lake processors: broken hyper-threading

lists.debian.org

201–210 of 278 posts

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

#201

Earlier quoted context omitted.

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…

Did you by chance see the paper a year back or so outlining that memory errors are more likely to occur near page boundaries? The author's premise was that a lot of 'cosmic rays' are just manufacturing flaws.

I debugged lots of memory corruption errors in my time working on AIX kernel stuff. Most of the ones I got to work on did indeed happen at a page boundary [1]. I think there is a pretty simple reason for this: "pages" are both the logical unit size of memory the kernel's allocator hands out, and the unit size that the hardware is capable of addressing in most cases. Therefore, when something at the kernel level is done incorrectly, it often references someone else's page.

It's also possible for a _byte_ offset to be wrong, and these types of errors need not occur at a page boundary. Useful things to do with a raw memory dump with this kind of corruption (at least in AIX kernel):

- Identify the page containing the corruption, and find all activity concerning the physical frame in the traces.

- Try to reverse engineer the bad data. Often times, there are pointers you can follow. You would have to manually translate the virtual address to physical frames, but that's pretty simple to do, both for user space and kernel space (in our case, it was always in kernel space, which was 64-bit and just used a simple prefix).

From there, you just have to be crafty and thorough in following the breadcrumbs and either identifying the bug in code, or at least who should investigate next.

In my original post, note that the corruption was on a _CPU cache_ boundary (128 bytes in POWER). IIRC, the containing page was allocated and pinned [2] for a longer time than the trace buffer tracked (it's been a few years, though).

[1] To make things fun, AIX and POWER supports multiple page sizes- 4K, 64K, 16MB, 16GB. Hardware also has the ability of promoting / demoting between 4K and 64K for in-use memory... lots of fun :-)

[2] AIX is a pageable kernel. If kernel code can't handle a page fault, it needs to "pin" the memory.

... note that any of this can be really outdated, it's been almost a decade since I was an expert in this stuff :-)

(Edit: formatting... how do you make a pretty bulleted list on HN??)

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

#202
post #31

There's a perl script on the debian mailing list that digs a bit deeper and tells you if you're affected in the first place, if you're affected but patched already, affected but have HT disabled, etc. https://lists.debian.org/debian-user/2017/06/msg01011.html

I ported this to bash since I have a chromebook w/o perl and (as for right now) the fs is read-only, so I just piped the script to it and sure enough my brand-new Samsung Chromebook Pro appears to be vulnerable, though apparently patchable.

Details and if you want the script I link to it from here: https://forum.xda-developers.com/hardware-hacking/chromebook... - don't judge my shitty bash skills.

ft

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

#203
post #65
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…

Here's a video of a tour of Nvidia's lab: https://www.youtube.com/watch?v=pRz_CG3DZb4

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

#204

Earlier quoted context omitted.

> High Register and 16bit registers are huge wart that it seems Intel is trying desperately hard to get us to stop using. Someone really ought to tell clang and gcc this; they both happily use 16-bit registers for 16-bit arithmetic. Anyway, Intel obviously already has special optimizations for many partial register accesses, dating back to Sandy Bridge. While it's quite possible that they left out the high registers…

Indeed, I've worked with CPUs that didn't have the register split of x86 and they are far less friendly to implementing certain algorithms, which would otherwise require many additional registers and lots of shift/add instructions to achieve the same effect. ("MOV AH, AL" being one simple example -- try doing that on a MIPS, for instance.)

How often have you really needed to do "a = (a & 0xffff00ff) | ((a & 0xff) Anyway, since you asked: In AArch64 that would be written "bfi w0,w0,#8,#8". "bfi" is an alias of "bfm", an instruction far more flexible and useful than any of the baroque x86 register names. BFM can move an arbitrary number of bits from any position in any register to any other register, and it has optional zero-extension and sign-extension modes.

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

#205

Earlier quoted context omitted.

Contact your laptop OEM.

Have you ever had to do this? The Dell XPS 9350 (Skylake) has numerous issues with GPU noise, USB-C compatibility, wifi reliability - Dell don't care unless your consumer laws are strong enough to make them care.

No but dell had a 30 day full refund policy. Did those bugs not start until day 31?

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

#206

Earlier quoted context omitted.

I don't think Ryzen has had any more or less bugs than the recent Intel generation. They are at least on the same order of magnitude. Ryzen is great, I might buy one next, but it is not to "doge bullets".

doge? :D

I need a better android keyboard

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

#207

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?

The same for any part of your computer, I imagine.

What happens when your laptop's display has frequently broken pixels?

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

#208

Earlier quoted context omitted.

Have you ever had to do this? The Dell XPS 9350 (Skylake) has numerous issues with GPU noise, USB-C compatibility, wifi reliability - Dell don't care unless your consumer laws are strong enough to make them care.

No but dell had a 30 day full refund policy. Did those bugs not start until day 31?

TBH, everything was covered by warranty other than the coil whine and wifi - by sticking to one particular driver version you can avoid many of the wifi issues. Not everyone has had the USB-C problems and it's gotten a little better with the most recent updates.

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

#209

Earlier quoted context omitted.

Indeed, I've worked with CPUs that didn't have the register split of x86 and they are far less friendly to implementing certain algorithms, which would otherwise require many additional registers and lots of shift/add instructions to achieve the same effect. ("MOV AH, AL" being one simple example -- try doing that on a MIPS, for instance.)

How often have you really needed to do "a = (a & 0xffff00ff) | ((a & 0xff) Anyway, since you asked: In AArch64 that would be written "bfi w0,w0,#8,#8". "bfi" is an alias of "bfm", an instruction far more flexible and useful than any of the baroque x86 register names. BFM can move an arbitrary number of bits from any position in any register to any other register, and it has optional zero-extension and sign-extension…

If you're talking to any memory-mapped registers, you'll be doing it all the time. Granted, you're much more likely to be using something like ARM to do that. x86 is a bit large/expensive/power hungry for embedded programming.

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

#210

Well, at least Intel acknowledges, documents and finally fixes these CPU bugs (via microcode updates). AMD on the other hand doesn't even acknowledge an issue when multiple customers report problems. See this Ryzen bug: https://community.amd.com/thread/215773

Huh? There are plenty of AMD employees in that thread who have acknowledged the problem. They're "looking into it", but just seem to have no progress to report yet, and suck at keeping people in the loop.

And at least one person near the end of the thread reports the problem occurs when ASLR is turned on, for what it's worth: https://community.amd.com/thread/215773?start=105&tstart=0
Post reply on HN