Some Ryzen Linux Users Are Facing Issues With Heavy Compilation Loads

I have an Asus Prime B350+ mainboard, and I chose it because it was the ONLY Asus Ryzen mainboard with regular PCI slots on it. I have my R7 1700 OC'd to 3.8GHz and RAM @ 2933. System is 8 hrs Prime95 w/AVX stable. I stopped it after 8 hours, because IMO 8 hours in testing is good enough. I am admittedly liquid cooling the chipset and VRMs on this board though, and it is running Windows. I realize this is a Linux thread, but I've had no problems at all with my B350 chipset mainboard and overclocking an 8 core CPU.

And this system just finished a 4 solid day video encoding marathon with the CPU pegged pretty much the entire time. I decided to re-rip and re-encode a bunch of my BluRays at a higher bitrate now that I can see banding in some of them on my new 4K TV (Movies are stored on my home NAS so I can keep my disks safely locked up. Children...).
 
mvmiller12 said:
I have an Asus Prime B350+ mainboard, and I chose it because it was the ONLY Asus Ryzen mainboard with regular PCI slots on it. I have my R7 1700 OC'd to 3.8GHz and RAM @ 2933. System is 8 hrs Prime95 w/AVX stable. I stopped it after 8 hours, because IMO 8 hours in testing is good enough. I am admittedly liquid cooling the chipset and VRMs on this board though, and it is running Windows. I realize this is a Linux thread, but I've had no problems at all with my B350 chipset mainboard and overclocking an 8 core CPU.

And this system just finished a 4 solid day video encoding marathon with the CPU pegged pretty much the entire time. I decided to re-rip and re-encode a bunch of my BluRays at a higher bitrate now that I can see banding in some of them on my new 4K TV (Movies are stored on my home NAS so I can keep my disks safely locked up. Children...).
Click to expand...

But you have a clue , other people read this and could think: hey it is do able, they skip over the part where you explain you have the VRM and chipset liquid cooled (would be nice if you could share a picture of it on this forum somewhere :) ) .

But without the cooling solution you created you would not ever attempt to run 8 core under load for 8 hours on B350.
 
Pieter3dnow said:
The link you posted holds so many comments by so many different people even the ones that don't have the bug you fail to produce _anything_ cept that some people have it. You call it in bug in Ryzen yet AMD has trouble reproducing it or there would be a fix.
Click to expand...

Did you read the links given including the one about the patch is being proposed to BSD kernel to alleviate the bug (i.e. the link that starts with "There is a bug in Ryzen related to the...")? Or will you continue in denial mode forever. A sincere answer would be clarify if i must add your subsequent posts to ignote.
 
juanrga said:
Funny considering that your only post in this thread doesn't add anything of value.
Click to expand...

I read your Ryzen Predictions page and let me say, it does not surprise me that you would respond like this. The entire page was nothing more than, I am right, they are wrong, see, see, SEE! Therefore, feel free to ignore if you prefer but, that will not change who you are. By the way, Ryzen has kicked ass, just the way it is. :)
 
ManofGod said:
I read your Ryzen Predictions page and let me say, it does not surprise me that you would respond like this. The entire page was nothing more than, I am right, they are wrong, see, see, SEE! Therefore, feel free to ignore if you prefer but, that will not change who you are. By the way, Ryzen has kicked ass, just the way it is. :)
Click to expand...
yet by Feb we all knew what was coming, so not that special.

OT seems if there were an inherent CPU issue it would affect all users. And being the few that do and 100%(required) load leads more to software scheduling or instabilities rather than an errata or similar issue.
 
juanrga said:
Did you read the links given including the one about the patch is being proposed to BSD kernel to alleviate the bug (i.e. the link that starts with "There is a bug in Ryzen related to the...")? Or will you continue in denial mode forever. A sincere answer would be clarify if i must add your subsequent posts to ignote.
Click to expand...

Which means absolutely nothing , there so many proposals for these kind of things unless a kernel developer can replicate the problem you can make proposals until you are blue in the face.

Maybe you need to learn to quote but then again that is already asking to much of you. The only person that is in denial are you, since there are some people that do not have this bug. You linked to a reply by someone with a B350 based machine running 8 cores and having problems which I linked you the video which shows the B350 platform can't do this without problems of a hardware nature. upon this post https://hardforum.com/threads/some-...pilation-loads.1936605/page-3#post-1043060783

Shows you that you can run it with 8 cores but only if you apply cooling solution as mvmiller12 did.
 
Pieter3dnow said:
Which means absolutely nothing , there so many proposals for these kind of things unless a kernel developer can replicate the problem you can make proposals until you are blue in the face.

Maybe you need to learn to quote but then again that is already asking to much of you. The only person that is in denial are you, since there are some people that do not have this bug. You linked to a reply by someone with a B350 based machine running 8 cores and having problems which I linked you the video which shows the B350 platform can't do this without problems of a hardware nature. upon this post https://hardforum.com/threads/some-...pilation-loads.1936605/page-3#post-1043060783

Shows you that you can run it with 8 cores but only if you apply cooling solution as mvmiller12 did.
Click to expand...

We already know he is wrong cause if AMD had said there was a bug and they are fixing it he would have posted it all over. Also errata tends to be easily duplicated since everyone has the issue.
 
Pieter3dnow said:
But you have a clue , other people read this and could think: hey it is do able, they skip over the part where you explain you have the VRM and chipset liquid cooled (would be nice if you could share a picture of it on this forum somewhere :) ) .

But without the cooling solution you created you would not ever attempt to run 8 core under load for 8 hours on B350.
Click to expand...

I have a picture of the inside of the machine, but it is using soft tubing, so it looks like quite the mess of computer intestines :). Also, the pinched tubing in the picture has been repaired. When money presents itself, I am seriously considering re-doing the radiator, pump/reservoir, flow meter portions of the loops (there are 2) with hard tubing, and leaving the component pieces themselves on soft tubing with the quick disconnects - the best of both worlds for neatness and accessibility. There is currently a LOT of excess tubing in there to prevent kinks.

The VRMs can be seen in the picture, but not very well. The chipset cooler is also largely obscured by the video card.I ended up getting a little creative with the VRM block mounting because the VRM area on the right side of the board is shorter than the actual block. I had to use the smallest Koolance VRM block plate and mount the cooler using a mainboard support hole. I put a flat-topped plastic post in that location in the case to still provide support.Works a treat. I also modded a Koolance 390 AM4 adapter kit to work on the 380 block. The mounting holes for the block are on the adapter, but they needed to be drilled through to screw on to the 380 block - apparently the 390 no longer has it's brackets screwed onto the block.

WP_20170316_15_54_55_Pro.jpg
 
mvmiller12 said:
I have a picture of the inside of the machine, but it is using soft tubing, so it looks like quite the mess of computer intestines :). Also, the pinched tubing in the picture has been repaired. When money presents itself, I am seriously considering re-doing the radiator, pump/reservoir, flow meter portions of the loops (there are 2) with hard tubing, and leaving the component pieces themselves on soft tubing with the quick disconnects - the best of both worlds for neatness and accessibility. There is currently a LOT of excess tubing in there to prevent kinks.

The VRMs can be seen in the picture, but not very well. The chipset cooler is also largely obscured by the video card.I ended up getting a little creative with the VRM block mounting because the VRM area on the right side of the board is shorter than the actual block. I had to use the smallest Koolance VRM block plate and mount the cooler using a mainboard support hole. I put a flat-topped plastic post in that location in the case to still provide support.Works a treat. I also modded a Koolance 390 AM4 adapter kit to work on the 380 block. The mounting holes for the block are on the adapter, but they needed to be drilled through to screw on to the 380 block - apparently the 390 no longer has it's brackets screwed onto the block.

View attachment 27890
Click to expand...
doesn't matter what it looks like as long as it works.
 
Pieter3dnow said:
Which means absolutely nothing , there so many proposals for these kind of things unless a kernel developer can replicate the problem you can make proposals until you are blue in the face.
Click to expand...

Precisely the guy that identified the bug on RyZen is a kernel developer...

Pieter3dnow said:
Maybe you need to learn to quote but then again that is already asking to much of you. The only person that is in denial are you, since there are some people that do not have this bug. You linked to a reply by someone with a B350 based machine running 8 cores and having problems which I linked you the video which shows the B350 platform can't do this without problems of a hardware nature. upon this post https://hardforum.com/threads/some-...pilation-loads.1936605/page-3#post-1043060783
Click to expand...

Wait! Didn't you read the several post here or the links given with people on X370 boards is also experiencing the problem?
 
juanrga said:
Precisely the guy that identified the bug on RyZen is a kernel developer...
Wait! Didn't you read the several post here or the links given with people on X370 boards is also experiencing the problem?
Click to expand...

If you only had some basic knowledge about hardware. Check out the picture from mvmiller12 , then wonder why I made the comments about the B350 board having trouble with errors if used without such a solution. Then wonder why are faults appearing because I'm not saying that there are no errors , just saying that the cause of the errors might not be Ryzen in the first place.

There so many posts in the community thread some claiming this helped other saying it did not work for them. You pick which is which and of those are truly having problems with Ryzen or just hardware/bios problems ?
 
os2wiz said:
removed
Click to expand...

Attacking people that post information you don't want to hear doesn't add value. And what is more important, the problems that people is experiencing will not go away.

Pieter3dnow said:
I'm not saying that there are no errors , just saying that the cause of the errors might not be Ryzen in the first place.
Click to expand...

Then what part of "There is a bug in Ryzen" from the BSD patch you don't get?
 
Last edited by a moderator:
juanrga said:
Attacking people that post information you don't want to hear doesn't add value. And what is more important, the problems that people is experiencing will not go away.



Then what part of "There is a bug in Ryzen" from the BSD patch you don't get?
Click to expand...

+1 this.
 
Please, guys. Be civil!
Bickering between each other this way does not add to the discussion. If you can't post anything constructive, then don't do it. You are wasting mine and other's time because you are making us read your posts. And I can't even tell from half of the posts which side the poster is even on.
 
Last edited by a moderator:
Pieter3dnow said:
But you have a clue , other people read this and could think: hey it is do able, they skip over the part where you explain you have the VRM and chipset liquid cooled (would be nice if you could share a picture of it on this forum somewhere :) ) .

But without the cooling solution you created you would not ever attempt to run 8 core under load for 8 hours on B350.
Click to expand...

B350's with R5 1600 or R7 1700's will do just fine. Overclocking probably will not but, then again, if you know what you are doing, you will buy the right thing to do so.
 
ManofGod said:
B350's with R5 1600 or R7 1700's will do just fine. Overclocking probably will not but, then again, if you know what you are doing, you will buy the right thing to do so.
Click to expand...
I think the point is very specific to this situation as far as b350 is concerned. The load is extreme and why some think it is stability related be it OCs/voltages or software scheduling. I am more inclined toward software as some are stock clocked.
 
juanrga said:
https://www.phoronix.com/scan.php?page=news_item&px=Ryzen-Compiler-Issues

It originally looked as an bug on GCC, but last research seems to confirm this is part of the older SMT/uop bug. Remember that earlier engineering samples had uop or the SMT disabled due to this bug. It seems that the bug wasn't completely corrected in retail chips. The problem seems to be traced down to the IRETQ instruction and it is not reproducible when threads are running on different cores.

AMD is recommending to disable SMT

https://community.amd.com/thread/216084
https://community.amd.com/message/2796982

Surely a microcode update will fix this.
Click to expand...
juanrga said:
Attacking people that post information you don't want to hear doesn't add value. And what is more important, the problems that people is experiencing will not go away.



Then what part of "There is a bug in Ryzen" from the BSD patch you don't get?
Click to expand...
gigatexal said:
+1 this.
Click to expand...

What part of linking threads and posting your own opinion on top of it don't you get ?
You post about things you don't understand. Case in point your 1st post.

You claim that AMD is saying to disable SMT that would fix it according to what you wrote here. I haven't seen in any thread that would work for everyone , what you are doing here is creating a situation where you just say something suggest it comes from AMD and suggest it works, you did this not AMD.

You acknowledge it here yourself:

juanrga said:
No official answer still from AMD. They continue investigating the issue, and their last recommendation was to disable uop or SMT

https://community.amd.com/thread/215773

DragonFly BSD has a partial workaround for the RyZen bug. The bug is not solved but its frequency of reproduction is reduced

http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/b48dd28447fc8ef62fbc963accd301557fd9ac20
Click to expand...

You interject your own opinion while there is no official answer from AMD.

I'm saying you are purposely trolling this. You have been from day 1 on this board. You contradict yourself you don't post any relevant information.

I have yet to see 1 post from you on this subject with a clear solution to this problem. Or a clear outline on which users have this problem. You move goal posts and claim to be a victim of personal attacks , then post something relevant to the issue.

You can not even discern what is impossible in hardware to run a full load 1800x on any current B350 board and not get errors (Linux or windows for that matter) .
 
Pieter3dnow said:
You claim that AMD is saying to disable SMT that would fix it according to what you wrote here. I haven't seen in any thread that would work for everyone , what you are doing here is creating a situation where you just say something suggest it comes from AMD and suggest it works, you did this not AMD.
Click to expand...

Do you even read what you quote? You are quoting me saying "AMD is recommending to disable SMT" and "their last recommendation was to disable uop or SMT". I didn't say it would work for everyone.

From the amdcommunity link

Hi Folks,

I appreciate your patience and i have some suggestions you can try.

In the Asus BIOS there is an option called called OPCache Control. Disabling this may resolve this issue.

Another suggestion is to try disabling SMT. Look for an option in the Bios called 'Disable SMT'.

Please try one or both of the suggestions above depending on which Motherboard you have and let me know how you get on.
Click to expand...

Disabling SMT only helps some users to reduce the frequency of repetition of the problem

To be fair to amdmatt's suggestions, disabling SMT is the one thing that makes the biggest difference for my system stability while compiling. My test compile of mesa-17.0 was able to successfully complete nearly 14 times in a row before crashing with SMT disabled and make reduced to -j8. That said, I still don't feel that this is an acceptable solution - I didn't buy a 16-thread processor to run it with half the threads disabled (and even then not be 100% sure that it's not going to crash, or corrupt my data).
Click to expand...

The problem is traced to a bug on RyZen that was identified time ago by a kernel developer. A temporary patch is being added to Dragonfly BSD

There is a bug in Ryzen related to the kernel iretq'ing into a high user
%rip address near the end of the user address space (top of user stack).
This is a temporary workaround for the issue.
Click to expand...


AMD remains silent since the last post the day 1 June in the amdcommunity thread. They continue "investigating the issue". But I got unofficial word they are preparing a microcode update.

Pieter3dnow said:
You can not even discern what is impossible in hardware to run a full load 1800x on any current B350 board and not get errors (Linux or windows for that matter) .
Click to expand...

It was also made clear in this thread that people is having the same problem on X370 mobos: MSI X370 Gaming Pro Carbon, ASRock Taichi x370, MSI X370 SLI Plus, ASUS PRIME X370-pro,...

Could you and others stop pretending it is a problem with B350 mobos?
 
Last edited:
juanrga said:
Do you even read what you quote? You are quoting me saying "AMD is recommending to disable SMT" and "their last recommendation was to disable uop or SMT". I didn't say it would work for everyone.

From the amdcommunity link



Disabling SMT only helps some users to reduce the frequency of repetition of the problem



The problem is traced to a bug on RyZen that was identified time ago by a kernel developer. A temporary patch is being added to Dragonfly BSD




AMD remains silent since the last post the day 1 June in the amdcommunity thread. They continue "investigating the issue". But I got unofficial word they are preparing a microcode update.



It was also made clear in this thread that people is having the same problem on X370 mobos: MSI X370 Gaming Pro Carbon, ASRock Taichi x370, MSI X370 SLI Plus, ASUS PRIME X370-pro,...

Could you and others stop pretending it is a problem with B350 mobos?
Click to expand...
Pretending is what your doing in regards to the subject. Look more closely at the issue and the reports. It looks a lot more like a software issue ie: kernel issue with the ryzen CPU. And sorry one person giving advice is not the same as an Official statement. You are drawing far too many conclusions only to serve your goals in this witchhunt.
 
JustReason said:
Pretending is what your doing in regards to the subject. Look more closely at the issue and the reports. It looks a lot more like a software issue ie: kernel issue with the ryzen CPU. And sorry one person giving advice is not the same as an Official statement. You are drawing far too many conclusions only to serve your goals in this witchhunt.
Click to expand...

So software doesn't run correctly on Zen you say? There is something called compatibility for a reason.
 
JustReason said:
And sorry one person giving advice is not the same as an Official statement.
Click to expand...

That person is working for AMD and responding to users about this problem in the name of AMD. Sure yuo have noticed the string "AMD" in his nickname. What he said is an official statement until someone else at AMD above him says otherwise.
 
juanrga said:
That person is working for AMD and responding to users about this problem in the name of AMD. Sure yuo have noticed the string "AMD" in his nickname. What he said is an official statement until someone else at AMD above him says otherwise.
Click to expand...

Wrong. He can make any number of statements none of which are official for AMD as a company. When AMD makes an official statement they will do it through official channels. I can go online and make any number of statements concerning products from the company I work for and trust me none of them would be official. Try making a legal case based on such statements and see how "official" they are received.
 
JustReason said:
Wrong. He can make any number of statements none of which are official for AMD as a company. When AMD makes an official statement they will do it through official channels. I can go online and make any number of statements concerning products from the company I work for and trust me none of them would be official. Try making a legal case based on such statements and see how "official" they are received.
Click to expand...

If you are working in the sales dept. of AMD and then posting during the week-end your personal statements about technical issues in third party forums external to your company, your posts don't have official validity. But this is not the case is being noticed. Matt is the person choosen by AMD to reply tickets about technical matters in the official support channel created by AMD. He is talking in representation of AMD, under the title of "Technical Support Engineer", to solve the tickets opened by users of products of AMD. That is why the talks in plural such as "we're looking at the issue", "We're still investigating the issue", "There is no need to open new tickets on this issue. We are investigating"... and that is why he creates documents with official instructions, for instance about how to enable stuff in AMD hardware

https://community.amd.com/docs/DOC-1432
 
juanrga said:
If you are working in the sales dept. of AMD and then posting during the week-end your personal statements about technical issues in third party forums external to your company, your posts don't have official validity. But this is not the case is being noticed. Matt is the person choosen by AMD to reply tickets about technical matters in the official support channel created by AMD. He is talking in representation of AMD, under the title of "Technical Support Engineer", to solve the tickets opened by users of products of AMD. That is why the talks in plural such as "we're looking at the issue", "We're still investigating the issue", "There is no need to open new tickets on this issue. We are investigating"... and that is why he creates documents with official instructions, for instance about how to enable stuff in AMD hardware

https://community.amd.com/docs/DOC-1432
Click to expand...
Still not official just because he states it. I know of the guy and have had plenty of conversations. At best he has insider knowledge but in no way is he responsible for making official statements. He can ferry them if need be but forums are not and have never been the correct medium for official statements.
 
Shintai said:
If you agree to that...

So what else is Zen incompatible with if it doesn't follow x86 compatibility? :)
Click to expand...

Processors have erratum, whether they be designed by Intel or AMD. If it is fixable via microcode update, I'm sure they will. If ti requires a new spin of the processor, they'll do that, and you'll either buy the new revision or live with/work around the problem (it is exceedingly rare for CPUs to get replaced for erratum. In fact I've only ever heard of it happening with the ancient Pentium FDIV bug, and then only on a case-by-case basis)


The point is that Intel and AMD are equally x86 compatible, but shit happens sometimes - to both.
 
mvmiller12 said:
Processors have erratum, whether they be designed by Intel or AMD. If it is fixable via microcode update, I'm sure they will. If ti requires a new spin of the processor, they'll do that, and you'll either buy the new revision or live with/work around the problem (it is exceedingly rare for CPUs to get replaced for erratum. In fact I've only ever heard of it happening with the ancient Pentium FDIV bug, and then only on a case-by-case basis)


The point is that Intel and AMD are equally x86 compatible, but shit happens sometimes - to both.
Click to expand...

Agree, people just need to accept it instead of pretending nothing is wrong and its someone else fault.
 
mvmiller12 said:
Processors have erratum, whether they be designed by Intel or AMD. If it is fixable via microcode update, I'm sure they will. If ti requires a new spin of the processor, they'll do that, and you'll either buy the new revision or live with/work around the problem (it is exceedingly rare for CPUs to get replaced for erratum. In fact I've only ever heard of it happening with the ancient Pentium FDIV bug, and then only on a case-by-case basis)


The point is that Intel and AMD are equally x86 compatible, but shit happens sometimes - to both.
Click to expand...

It seems a new spin of Zen silicon is being prepared. This B2-step seems to focus only on Uncore/SoC erratas (PCIe controllers, etc.).
 
Shintai said:
Agree, people just need to accept it instead of pretending nothing is wrong and its someone else fault.
Click to expand...
Pieter3dnow said:
If you only had some basic knowledge about hardware. Check out the picture from mvmiller12 , then wonder why I made the comments about the B350 board having trouble with errors if used without such a solution. Then wonder why are faults appearing because I'm not saying that there are no errors , just saying that the cause of the errors might not be Ryzen in the first place.

There so many posts in the community thread some claiming this helped other saying it did not work for them. You pick which is which and of those are truly having problems with Ryzen or just hardware/bios problems ?
Click to expand...

Reading what people say is not required I guess ... You are also ignoring what I wrote about the B350 board and 8 cores under load , maybe you have insight regarding that as well since you do know everything. Hows your piggy bank going these days Shintai ?
 
juanrga said:
blah blah blah blah
Click to expand...

So you finally posted the official message from AMD it took you almost 100 posts in the thread to do so. Someone might ask why is it that you will post stuff without any validation behind it?

Since you posted this let me post what I found on the AMD community link:

mcl00 02-Jun-2017 13:05 (in response to amdmatt)
I am having exactly the same issues as the original poster (and the numerous others that have posted on the gentoo forum linked in the original message). I do not have an OP Cache setting in my motherboard (MSI X370 Gaming Pro Carbon) so I am not able to disable it. Turning off SMT does not fix the problem.
Click to expand...

And follows up with:
I have tried various combinations of the following with little to no effect:
Disabling SMT
Disabling Cool'n'Quiet
Varying clock speeds and timings of my RAM (Corsair 3200MHz) as low as 1866MHz CL 16.
Using the "performance" CPU governor.
Various LLC settings from auto (off?) through 4.
Setting the NB voltage up to 1.15V
Click to expand...

and he adds:

While the problem encountered is 'random' segmentation faults in that they do not occur in any fixed memory address or particular part of a compile, the system will very consistently crash / segfault in any highly multi-threaded process that uses a lot of RAM. To reproduce the issue, I simply loop through compiling mesa 17.0 with -j16 and the build directory mounted to tmpfs (i.e. a ramdisk location for the build files). If I make it past 10 minutes without a segfault it's a lucky run.
Click to expand...

the person also knows how to rule out certain aspects of how hardware might be at fault and posts:
I can't monitor CPU temperatures within Linux yet, but this does not appear to be heat related - cool ambient temperatures with the case open and a room fan blowing directly into the case did not increase the stability to any noticeable degree (and the CPU temperatures in Windows running prime95 with 16 workers stay reasonable).
Click to expand...

Note that this problem is not limited to compilation tasks in Linux - prime95 will throw errors as well. It's just much less frequent (e.g. where compiling mesa in a ramdisk will segfault in minutes, prime95 can go for a few hours before complaining.)
EDIT: I forgot to mention I also tried each of my memory sticks (2x8GB) independently without any improvement. If one stick was bad, you would expect to see segfaults with that stick but not the other. Both sticks together and each independently all display the same behaviour. Note that I haven't tried every combination of settings with every permutation of memory installed - just the default settings with the single DIMMs.)
Additionally, memtest86 will run through at least two cycles without error even with the RAM set at 3200MHz.
Click to expand...

Now you know when people say things that are obvious can only be ruled out by people posting correct information. Your posts lack any valid information from sources which makes it hard to read.
Throughout the thread you can read that SMT disabling does not help and the micro op cache can only be disabled on Asus motherboards. Check any of your posts before https://hardforum.com/threads/some-...pilation-loads.1936605/page-3#post-1043062721

Still waiting for you to post some things that can actually help people with Linux ...
 
AMD Readies B2 Stepping of the Ryzen "Summit Ridge" Silicon
by btarunr Monday, June 19th 2017 06:55 Discuss (28 Comments)
AMD is readying a new stepping of its 14 nm "Summit Ridge" eight-core CPU silicon, which powers its socket AM4 Ryzen processors, according to Canard PC. The new B2 stepping reportedly addresses a lot of hardware-level errata which cannot be fixed merely by AGESA updates. According to Canard PC, the changes seem to be focused on the uncore components of "Summit Ridge." Typically, uncore refers to the integrated northbridge, which includes components such as the memory controllers, PCI-Express root complex, etc.

If the B2 stepping is mostly focused on uncore-level errata, it could mean improved PCI-Express device support, and perhaps even memory support improvements beyond even what AGESA 1.0.0.6 brings to the table. Canard PC reports that it hasn't come across any CPU core-specific errata being addressed with the B2 stepping. The glaring FMA3-related bug has been patched through BIOS updates, and most newer batches of socket AM4 motherboards come with the patch pre-installed

Think this is Canard PC
 
gigaxtreme1 said:
AMD Readies B2 Stepping of the Ryzen "Summit Ridge" Silicon
by btarunr Monday, June 19th 2017 06:55 Discuss (28 Comments)
AMD is readying a new stepping of its 14 nm "Summit Ridge" eight-core CPU silicon, which powers its socket AM4 Ryzen processors, according to Canard PC. The new B2 stepping reportedly addresses a lot of hardware-level errata which cannot be fixed merely by AGESA updates. According to Canard PC, the changes seem to be focused on the uncore components of "Summit Ridge." Typically, uncore refers to the integrated northbridge, which includes components such as the memory controllers, PCI-Express root complex, etc.

If the B2 stepping is mostly focused on uncore-level errata, it could mean improved PCI-Express device support, and perhaps even memory support improvements beyond even what AGESA 1.0.0.6 brings to the table. Canard PC reports that it hasn't come across any CPU core-specific errata being addressed with the B2 stepping. The glaring FMA3-related bug has been patched through BIOS updates, and most newer batches of socket AM4 motherboards come with the patch pre-installed

Think this is Canard PC
Click to expand...


It's a bunch of nothing. It fixes uncore-level errata according to Canard but then he has no clue what that is? There may be in fact a B2 stepping coming but so far we have no idea why and this little blurb is garbage without any substance. Not surprising Juanrga regurgitated it on here, more surprised he was unwilling to say where he got it from.
 
If I had to guess a lot of the uncore fixes are probably for the server world (multi socket and MDM) where the SoC features of Zeppelin are put to use and the Infinity Fabric needs to be 110% stable for off die communication

They crowdsourced their server validation :cool: ;):p
 
linux folks are working overtime finding CPU bugs:
https://lists.debian.org/debian-devel/2017/06/msg00308.html
TL;DR: unfixed Skylake and Kaby Lake processors could, in some
situations, dangerously misbehave when hyper-threading is enabled.
Disable hyper-threading immediately in BIOS/UEFI to work around the
problem. Read this advisory for instructions about an Intel-provided
fix.
Click to expand...

Already in hardocp.com too:
https://www.hardocp.com/news/2017/0...ocessors_allegedly_have_broken_hyperthreading
 
You must log in or register to reply here.
Back
Top