Live data from Hacker News

Ryzen CPU HyperThreads break if 100% busy and interrupted to top of Memory

svnweb.freebsd.org

31–40 of 70 posts

Re: Ryzen CPU HyperThreads break if 100% busy and interrupted to top of Memory

#31

Its like we have all collectively forgotten that the first release of a hardware or software project is just an expensive beta. I don't buy 1st gen microarches because i'm not interested in paying top dollar to be a tester. What I find odd, is that apparently both intel and AMD have also forgotten this, as Intel seems to be moving toward making their enterprise customers the beta testers, while AMD seems so desperate…

I got used to the idea of staying away from the cutting edge in the early 2000's. The original Athlon and Thunderbird processors were groundbreaking in performance, but consumer cooling and PSU design had not caught up with their power and heat output demands - the result was uncomfortably noisy and hot at best. The high end parts really are like Ferraris in that they do take more of your time and care to deal with issues like that.

Now when I look at new machines and components I look for something slightly middle-of-the-road, mainstream-leaning, with low power output but quality components, and later revisions of an architecture, since system performance is a more-than-the-sum-of-its-parts game. I actually priced out a Ryzen 3 build today, but I might be better served with the last gen APUs.

Re: Ryzen CPU HyperThreads break if 100% busy and interrupted to top of Memory

#32
post #29

Its like we have all collectively forgotten that the first release of a hardware or software project is just an expensive beta. I don't buy 1st gen microarches because i'm not interested in paying top dollar to be a tester. What I find odd, is that apparently both intel and AMD have also forgotten this, as Intel seems to be moving toward making their enterprise customers the beta testers, while AMD seems so desperate…

AMD's not doing a recall, it works decently enough for most applications. Their response is going to be "if it crashes your application, turn SMT off". Consider they didn't even do a recall when Phenom had a showstopping TLB bug, they shipped a BIOS patch that disabled TLB entirely. And remember, Epyc is on a new stepping of the silicon, it's possible this is already fixed on it. (Threadripper is not, however)

> Their response is going to be "if it crashes your application, turn SMT off".

it happens when SMT is disabled

>Epyc is on a new stepping of the silicon, it's possible this is already fixed on it. (Threadripper is not, however)

that's assuming they caught this bug, which i doubt is the case because it's only discovered now rather than being documented in the errata.

Re: Ryzen CPU HyperThreads break if 100% busy and interrupted to top of Memory

#34
post #20

I bought a custom-built Rzyen-based PC around Easter, and I have experienced some issues with it; I am not sure, though, were to put the blame (CPU, motherboard/firmware, operating system (which is openSUSE Tumbleweed)). Under heavy load, the machine has performed most gracefully. However, the machine does freeze (almost) completely when left idle for a while (usually > 1 hour). When it happens, it sometimes still re…

> When it happens, it sometimes still responds to pings, but nothing more; if I try to ssh into it from my laptop, I do not even receive a TCP ACK.

Interesting. Pinging is handled entirely by the kernel. I wonder if the ACK code path has to enter and leave userspace before the response comes out the network card?

If disabling C6 (as per other comments) doesn't fix it, one possible place to start would be

1. Something like "while true; do date > file; sync; sleep 1; done" to track when userspace dies. (Okay, a proper C program that does fdatasync() just for that file would probably be better.)

2. Get inspired by http://elixir.free-electrons.com/linux/latest/source/drivers..., which borrows your system's RTC as non-volatile storage with simple write semantics - maybe you can borrow the year/month fields to store the current HH:MM. If on reboot the stored value matches wall clock time from another source (synced with the PC beforehand) at the moment you pull the plug, the kernel was still running. Then you could eg use the whole value to trace kernel locks and major mutexes etc.

3. Actually, if you can ping the kernel and that works, you could abuse the network stack to get data out!! Eg, pinging with certain bits set in the packet could trigger some magic code that returns system info. ICMP PING tunneling is a thing, and you could totally use this.

"But... I just want to use my computer..."

That's fair - waiting for someone else to fix everything works too :P

Re: Ryzen CPU HyperThreads break if 100% busy and interrupted to top of Memory

#36
post #29

Its like we have all collectively forgotten that the first release of a hardware or software project is just an expensive beta. I don't buy 1st gen microarches because i'm not interested in paying top dollar to be a tester. What I find odd, is that apparently both intel and AMD have also forgotten this, as Intel seems to be moving toward making their enterprise customers the beta testers, while AMD seems so desperate…

AMD's not doing a recall, it works decently enough for most applications. Their response is going to be "if it crashes your application, turn SMT off". Consider they didn't even do a recall when Phenom had a showstopping TLB bug, they shipped a BIOS patch that disabled TLB entirely. And remember, Epyc is on a new stepping of the silicon, it's possible this is already fixed on it. (Threadripper is not, however)

This is why I buy Intel.

Re: Ryzen CPU HyperThreads break if 100% busy and interrupted to top of Memory

#37
I hoped this just affected Ryzen CPUs, but this Reddit post indicates that it affects Epyc also: https://www.reddit.com/r/Amd/comments/6rmq6q/epyc_7551_minin...

The first post on on AMD's community forum (https://community.amd.com/thread/215773?start=0&tstart=0) is almost three months old, so AMD have known about this for a long time. If it's not something that can be fixed in a UEFI update, then it's bad news for everyone: a weakened AMD means more stagnation in amd64

Re: Ryzen CPU HyperThreads break if 100% busy and interrupted to top of Memory

#38
post #37

I hoped this just affected Ryzen CPUs, but this Reddit post indicates that it affects Epyc also: https://www.reddit.com/r/Amd/comments/6rmq6q/epyc_7551_minin... The first post on on AMD's community forum ( https://community.amd.com/thread/215773?start=0&tstart=0 ) is almost three months old, so AMD have known about this for a long time. If it's not something that can be fixed in a UEFI update, then it's bad news for…

So he's got a segfault every couple of minutes, wow... I've been running the same test for over 4 hours now on my Ryzen 1700 (and I've had several uneventful 30-40 minute runs before). To date, I only got one "internal compiler error: Illegal instruction" but no segfaults.

Whatever it is, it doesn't affect every chip the same way.

Re: Ryzen CPU HyperThreads break if 100% busy and interrupted to top of Memory

#39
post #37

I hoped this just affected Ryzen CPUs, but this Reddit post indicates that it affects Epyc also: https://www.reddit.com/r/Amd/comments/6rmq6q/epyc_7551_minin... The first post on on AMD's community forum ( https://community.amd.com/thread/215773?start=0&tstart=0 ) is almost three months old, so AMD have known about this for a long time. If it's not something that can be fixed in a UEFI update, then it's bad news for…

So he's got a segfault every couple of minutes, wow... I've been running the same test for over 4 hours now on my Ryzen 1700 (and I've had several uneventful 30-40 minute runs before). To date, I only got one "internal compiler error: Illegal instruction" but no segfaults. Whatever it is, it doesn't affect every chip the same way.

Whatever it is, it doesn't affect every chip the same way

If it is marginal timing in some part of the chip, that combined with statistical process and environment variations, and the increasingly tiny geometries (which serve to amplify the variation) mean the problem could really occur quite randomly. Modern CPUs are pushing the limits in more ways than one, and IMHO this is what happens when they go too far.

Re: Ryzen CPU HyperThreads break if 100% busy and interrupted to top of Memory

#40
post #29

Its like we have all collectively forgotten that the first release of a hardware or software project is just an expensive beta. I don't buy 1st gen microarches because i'm not interested in paying top dollar to be a tester. What I find odd, is that apparently both intel and AMD have also forgotten this, as Intel seems to be moving toward making their enterprise customers the beta testers, while AMD seems so desperate…

AMD's not doing a recall, it works decently enough for most applications. Their response is going to be "if it crashes your application, turn SMT off". Consider they didn't even do a recall when Phenom had a showstopping TLB bug, they shipped a BIOS patch that disabled TLB entirely. And remember, Epyc is on a new stepping of the silicon, it's possible this is already fixed on it. (Threadripper is not, however)

No! I was going to buy threadripper for this very reason.
Post reply on HN