[Debunked] BSD team discovered a new hardware issue with Ryzen

[2FA]

3 minutes ago, huilun02 said:

I'm average joe running Windows on Ryzen. Should I be worried?

Where is my pitchfork?

Here you go 

[79wjd]

10 minutes ago, leadeater said:

Marking posts as funny is rather childish.

I can't decide if I should "agree" or "funny" this.....

[Notional]

[...]

 

/thread

Edited August 6, 2017 by Ryan_Vickers

[zMeul]

12 minutes ago, leadeater said:

@zMeul Instead of marking my post funny you could actually try an answer my very simple question.

I find your post funny because you actually say the source, the developers who discovered and reported the issue, are wrong - if that was supposed to be a joke, it's quite funny

if it's not a joke ... well then, go in peace

[Notional]

9 minutes ago, Haaselh0ff said:

 DONT kill the thread, we're having fun!!

Here's some more fun. To be precise the 151 erratas of Skylake. I guess this means the platform/cpu is broken and people should not buy into it. https://www3.intel.com/content/dam/www/public/us/en/documents/specification-updates/desktop-6th-gen-core-family-spec-update.pdf

 

Or maybe the 102 erratas on Kabylake?

https://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/7th-gen-core-family-spec-update.pdf

 

*Sigh* I guess Kabylake is broken too. Sorry guys, we have to go back to 486-DX4. Those erratas should be fixed by now.

[EPENEX]

An issue with a new CPU in BSD OS's? I'm really not surprised.

[leadeater]

41 minutes ago, zMeul said:

I find your post funny because you actually say the source, the developers who discovered and reported the issue, are wrong - if that was supposed to be a joke, it's quite funny

if it's not a joke ... well then, go in peace

No the actual source for what you quoted is not the link you posted as the source. Your source is quoting the real source as shown by the use of quotes then makes his own statements before and after that.

 

Here is the actual source, post #68: https://www.phoronix.com/forums/forum/hardware/processors-memory/955368-some-ryzen-linux-users-are-facing-issues-with-heavy-compilation-loads/page7

 

Your source is saying that the bug is not related to SMT and in fact you didn't actually quote anything from that source.

 

Quote

On Ryzen there is some sort of interaction between code running at the top of user memory address space and interrupts that can cause FreeBSD to either hang or silently reset. This sounds similar to the problem found with DragonFly BSD that was fixed with this commit:

 

https://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/b48dd28447fc8ef62fbc963accd301557fd9ac20

but our signal trampoline location was already lower than the address that DragonFly moved their signal trampoline to.  It also does not appear to be related to SMT as described here: 

 

https://www.phoronix.com/forums/forum/hardware/processors-memory/955368-some-ryzen-linux-users-are-facing-issues-with-heavy-compilation-loads?p=955498#post955498

 

since the system instability has been observed on FreeBSD with SMT disabled.  Interrupts to appear to play a factor since running a signal-intensive process on the first CPU core, which handles most of the interrupts on my machine, is far more likely to trigger the problem than running such a process on any other core. Also lower sv_maxuser to prevent a malicious user from using mmap() to load and execute code in the top page of user memory that was made available when the shared page was moved down.

 

Make the same changes to the 64-bit Linux emulator.

https://svnweb.freebsd.org/base?view=revision&revision=321899

 

It's rather confusing when you have a post that doesn't actually mention anything other than the source saying it is not this and that part is all you quote.

 

Here is what you should have used for the source: https://reviews.freebsd.org/D11780. This is the full commit chain with developer comments and this work started Jul 30th and the issue is:

Quote

Ryzen (AMD Family 17h) shows stability issues if code is executed near the top of user space. In our case that is the signal trampoline that resides in the amd64 shared page.

 

Move the shared page down by one page on Ryzen as a workaround.

 

The Linux changes are untested.

 

The core reason for the confusion is your quote has nothing at all to do with the bug which is what lead me to question why disabling SMT wouldn't fix the problem, your source is saying what you quoted is not correct.

 

[Misanthrope]

1 hour ago, zMeul said:

remember when me and others told "you" to stay away from Zen CPUs for at least ¹/₂ y? this is precisely why

Problems mostly on Linux and BSD most end users are not gonna run into 99% of the time was the reason? 

 

 

[VagabondWraith]

Ouch. This is really bad.

 

RIP AMD.

[Jito463]

1 hour ago, zMeul said:

remember when me and others told "you" to stay away from Zen CPUs for at least ¹/₂ y?

If the problem is really hardware based - and not software - then this issue definitely needs to be addressed.  However, the above comment is quite petty, even for you.

 

We all know how much you dislike AMD, and that's perfectly fine.  You're entitled to your own opinions and feelings.  However, using a potential bug to throw a "told you so" around (without merit, I may add), just makes you come across as childish and diminishes any point you wanted to make with this post.

[Fetzie]

16 minutes ago, VagabondWraith said:

Ouch. This is really bad.

 

RIP AMD.

It's an interrupt scheduling bug. Which part of the computer is responsible for interrupt scheduling? That's right, it's the OS.

[ScratchCat]

1 hour ago, Fetzie said:

It's an interrupt scheduling bug. Which part of the computer is responsible for interrupt scheduling? That's right, it's the OS.

http://www.informit.com/articles/article.aspx?p=2249436&seqNum=7

 

It seems like this is a problem when the interrupt controller being interrupted by an interrupt. This to me sounds more like a software bug , especially given that it supposedly  exists on other platforms. Hopefully this can be fixed in a simple way.

 

Disclaimer: I didn't understand half of the things in there.

[Vode]

3 hours ago, zMeul said:

you deny these issues exists?

no one has to listen to anything I "say", look at the sources I provide

 

the segmentation fault is 3 months old and AMD has yet to deal with it in one way or another

while at the same time they push server and workstation grade products that seem to be affected by the same issues the original desktop parts are - businesses will be thrilled that their new stations have unresolved HW issues

Where were you when the Skylake HT issue was discovered?

[Liltrekkie]

I really like when zMeul makes a thread and has no idea what he is talking about then acts like he's hot shit for shitting on AMD, when in fact, Intel processors have this same issue too, and my own personal Phenom II  x6 1055T and Intel 920 had this SAME issues. 

 

It's not like RAM faults are a thing? Or voltage drops? You know, as you use more RAM, a memory fault is more likely to happen, especially when using GCC workloads. FreeBSD is the same way, although, the way they work with multithreading is a bit funky. It's not a processor thing, it's a software and power delivery thing. When I don't use any load line calibration on my Phenom system, I will almost ALWAYS get a fault, even when at stock. A processor freaks the heck out when it's require voltage drops, even small amounts. 

 

I have to say I don't work with freebsd that often, because it's hit or miss on whether it works correctly on any system i've used. 

 

It's pretty amazing that everyone jumps to either a software or hardware bug, and yes, freebsd and GCC really need to update their stuff. 

 

 

[ravenshrike]

3 hours ago, Notional said:

Here's some more fun. To be precise the 151 erratas of Skylake. I guess this means the platform/cpu is broken and people should not buy into it. https://www3.intel.com/content/dam/www/public/us/en/documents/specification-updates/desktop-6th-gen-core-family-spec-update.pdf

 

Or maybe the 102 erratas on Kabylake?

https://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/7th-gen-core-family-spec-update.pdf

 

*Sigh* I guess Kabylake is broken too. Sorry guys, we have to go back to 486-DX4. Those erratas should be fixed by now.

Lets not forget Cougar Point or the Turbo bug in Nehalem.

 

https://www.theinquirer.net/inquirer/feature/2024145/intel-cougar-recall-helps-partner-relationship

 

http://www.semiaccurate.com/forums/archive/index.php/t-1130.html

 

[Fetzie]

1 hour ago, ScratchCat said:

http://www.informit.com/articles/article.aspx?p=2249436&seqNum=7

 

It seems like this is a problem when the interrupt controller being interrupted by an interrupt. This to me sounds more like a software bug , especially given that it supposedly  exists on other platforms. Hopefully this can be fixed in a simple way.

 

Disclaimer: I didn't understand half of the things in there.

How easily it can be fixed relies on how much of the OS needs to be rewritten.

[samcool55]

FAKE NEWS

Even in the tech world...

 

Don't topics like these that are proven incorrect get locked or something? O_o

[RagnarokDel]

6 hours ago, zMeul said:

source: https://svnweb.freebsd.org/base?view=revision&revision=321899

 

 

4 days ago the developers of FreeBSD have issued a report for a new issue they encountered with Ryzen CPUs:

the issue described has been observed on FreeBSD systems with SMT disabled

An issue with hyper-threading when it's disabled? You're just throwing shit at the wall in attempt to find something that will stick per usual.

 

PS: The Seg fault issue is an issue with PHP and doesnt happen only on Ryzen, it's a faulty test not a faulty CPU.

6 hours ago, leadeater said:

@zMeul Instead of marking my post funny you could actually try an answer my very simple question. It didn't need to be an argument at all, this issue is talking about SMT then you said it exists when SMT is disabled and I'd like to know how that is possible, not a hard question. Especially when the original source says the bug does not happen when the cpu-bound loop is on a different core than the core doing the IRETQ, the only way they can be run on the same core is with SMT.

 

Marking posts as funny is rather childish.

Not sure what you expected from him.

[Pample]

How are we suprised at all of this ... it's @zMeul on his anti AMD propaganda war once more. "Oh look, a brand new arch has some teething problems, how AMD have screwed up again". Both AMD AND Intel have had, and will continue to have issues with new architectures when they are so radical. 

 

Having had both Intel and AMD platforms, this is not something that worries me, nor should it anyone else (In my humble opinion). It's simple scaremongering to start telling people that there may be a full scale product recall on the horizon. Stop it and grow up.

[Fetzie]

6 minutes ago, Pample said:

How are we suprised at all of this ... it's @zMeul on his anti AMD propaganda war once more. "Oh look, a brand new arch has some teething problems, how AMD have screwed up again". Both AMD AND Intel have had, and will continue to have issues with new architectures when they are so radical. 

 

Having had both Intel and AMD platforms, this is not something that worries me, nor should it anyone else (In my humble opinion). It's simple scaremongering to start telling people that there may be a full scale product recall on the horizon. Stop it and grow up.

It isn't even teething problems with the new µArch, it's a barely-used operating system that is temperamental about hardware support to begin with that doesn't handle interrupts properly (the issue is reproduceable on Kabylake too).

[Snipeon]

6 minutes ago, Pample said:

How are we suprised at all of this ... it's @zMeul on his anti AMD propaganda war once more. "Oh look, a brand new arch has some teething problems, how AMD have screwed up again". Both AMD AND Intel have had, and will continue to have issues with new architectures when they are so radical. 

 

Having had both Intel and AMD platforms, this is not something that worries me, nor should it anyone else (In my humble opinion). It's simple scaremongering to start telling people that there may be a full scale product recall on the horizon. Stop it and grow up.

Well, let's just leave the fanboys to their antics while we watch on with popcorn on our laps.

[Pample]

9 minutes ago, Fetzie said:

It isn't even teething problems with the new µArch, it's a barely-used operating system that is temperamental about hardware support to begin with that doesn't handle interrupts properly (the issue is reproduceable on Kabylake too).

True, very true.

 

7 minutes ago, Snipeon said:

Well, let's just leave the fanboys to their antics while we watch on with popcorn on our laps.

Are you shouting the popcorn then? I'll bring the cola (Or Gin in my case).

[NvidiaIntelAMDLoveTriangle]

WHAT? @zMeul posted something bad about AMD our lord and savior???

Let's all hate on him.

[Taf the Ghost]

Obviously, zMeul's issues are his own, but this reminds me a lot of the original 1080p gaming results with Ryzen. Turns out is far less "Intel is better than AMD!" and far more "Nvidia's driver team is really freaking good!". As Nvidia's ability to exploit the Sandy Bridge & on uArch is really impressive. It's also why there's barely any gaming IPC difference between Sandy Bridge through Kaby Lake on Nvidia cards.

[Drak3]

4 minutes ago, NvidiaIntelAMDLoveTriangle said:

WHAT? @zMeul posted something bad about AMD our lord and savior???

Let's all hate on him.

Posting and making it seem like the issue will happen to every single person ever, when the reality is that the issue is only going to be seen working on specific workload, in certain operating systems.

The problem is that it turns out to be one of two things:

An issue of software, not hardware.

An issue that only occurs in specific workloads, under specific operating systems, with those operating systems being uncommon in the consumer space and those workloads being less than common within the user base of those operating systems.