Live data from Hacker News

Intel Skylake/Kaby Lake processors: broken hyper-threading

lists.debian.org

181–190 of 278 posts

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

#181
Do you need a professional hacker, contact cipherhacker1@GMAIL.COM Our service includes Change University grades Facebook, twitter, IG hack Email hack icloud and phone hack * grades change Wipe criminal records Wipe credit card debt MasterCard's/visa cards Bank account *Data base hack and lot more hacking services in general Among other customized services...all this are at all great rate. Results guaranteed. Contact us at cipherhacker1@GMAIL.COM

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

#182
I would've expected at least an example assembly code reproducing the bug? How was it not discovered before, but only with the OCaml compiler? They say "unexpected behavior", does this mean that code compiled with this can give incorrect results? Can this have any security implication? How much code was compiled with similar patterns? Can the problem reproduced with any JIT compiler? We need to know what can cause this, maybe compiled and working code already contains such patterns waiting to be abused...

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

#183
post #118

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 :)

Mobile dual-core lie5's have hyperthreading too.

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

#184
post #126

My CPU (6th generation i5) died last week. RIP. I installed debian 9, installed virtualbox, vagrant, setup a clean development machine for myself, everything took 4 hours to finish. I reboot the virtual machine, and boom, there was a kernel panic which I sadly don't remember exactly / didn't take a picture of. After I rebooted the machine, and opened terminal, the system froze. The cursor wouldn't move. Reboot again,…

CPUs rarely die, unless you're OCing or PSU went bad and took things out, I am willing to bet your MoBo is the part that is bad.

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

#185

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

The first reply is from an AMD employee..........

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

#186

Earlier quoted context omitted.

The problem with finding a physics bug is that it's liable to be amplifiable. Break conservation laws just a little bit and suddenly you have potential for exponential runaway leading to an unplanned reality excursion, and say goodbye to your light-cone.

Well, by definition the behaviour would be undefined so could go any which way. ;) Modern day VM software has various levels of exception checking, and code to catch/mitigate/etc when bugs crop up. So, a universe-capable simulator might have any kind of behaviour if/when a bug occurs. It doesn't need to be an unbounded, runaway scenario. :)

And, if a very bad reality excursion happens, you scrap that branch and restore the last checkpoint. Nobody inside the simulation will ever remember it. You only bother fixing it if halt/scrap/restore becomes a burden.

It probably happens more often than we imagine ;-)

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

#187

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…

I understand that someone at Microsoft Research once found a bug in the XB360's memory subsystem by model checking a TLA+ spec of it. The story goes that IBM initially refused to believe the bug report. A few weeks later they admitted that such a bug did indeed exist, had been missed by all their testing and would have resulted in system crashes after about 4 hours use.

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

#189
post #143
post #74

Earlier quoted context omitted.

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?

I agree. It's totally possible that Intel found the bug in another bug report, fixed it, closed that bug report, and never realized that the OCaml bug was related.

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

#190

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…

I feel like a lot of the processors Intel has released recently that have had problems like this. Intel's Bay Trail processors like the Celeron J1900 have a huge problem around power state management (https://bugzilla.kernel.org/show_bug.cgi?id=109051) that's unlikely to ever get resolved and makes those processors almost unusable under a lot of conditions (random hard hangs on systems without watch dog timers really kind of sucks). I wonder if Intel has been more lax recently with how the systems get tested?
Post reply on HN