Amd Ryzen 5 3600 Series

[Rocki Eibl]

Thanksfor the feedback provided about our supported list. We have shared the information given. We will pass the information on to the corresponding team in charge. Let us know if you have any questions.

Well, I can't give you that data anymore because I changed my processor, but hear me out, there's a reason why I changed the processor and I think you should remove Zen 2 CPUs from the supported list:

I tested with ReBar off, and i've noticed something VERY weird: My performance improved, on all of these games, and, most important, the stutters were mostly gone. But as Intel ARC GPUs perform better with ReBar ON, I indeed was underperforming comparing to other systems with ARC A750 graphics (looking from videos online).

Then I bought a second hand Ryzen 5600 to do some more digging, and my performance was, all of the sudden, much better, basically the same as in the reviews, and with the 5600 if I DISABLE ReBar, I lose performance, unlike with the 3600 that with ReBar OFF it improved its performance.

@Jean_Intel I know you probably need more data to report to your graphics development team, and I'm happy to provide it to you (I just don't have the 3600 anymore), but now I'm almost 100% sure it's something to do with poor ReBar implementation within Ryzen 3000 CPUs by AMD, I've had a Radeon 5600XT, a RX 6500XT and an RTX 3050 with the Ryzen 3600 before and they all also got worse performance with ReBar enabled. I'm sure if you guys do more testing with Ryzen 3000 CPUs combined with 500 series Motherboards you'll be able to replicate my (and a lot of people's) problem. I really think you should remove Zen 2 from the supported CPU list.

Would be perfect if you're able to report this directly to who makes this testings and drivers instead of giving me the usual customer service bureaucracy, I'm not with this problem anymore because I have changed my processor, but i'm willing to help the comunity as a whole!

I agree with this. I thank you for bringing this up!! The biggest issue here is that Intel should be testing more on the 3000/4000 series CPUs. With Rebar enabled, the game Control, ray tracing is horrifically stuttery with low frame rate (mid 20s at best). I just so happened to decide to disable rebar in bios and Control was then buttery smooth with ray tracing high. I can certainly say that the majority of tests that I completed were slower but only marginally however much more usable with rebar off.

Hey, @CaptainBennet , in my answer to @Jean_Intel comment, you can see I did some digging around this and I'm almost sure Zen 2 CPUs (Ryzen 3000 non-G and Ryzen 4000) have poor ReBar support, as with my testing I got WORSE performance with ReBar on.

Problem is that, although you'll get more stable performance disabling ReBar with your Ryzen 3600, you'll also not use near the full potential of your ARC GPU, as it will lose around 30% performance with ReBar off (compared to it's full potential).

I would recommend disabling ReBar and, if possible, flipping a 5600 or better, even a used one (now they're pretty cheap anyways). That's what I did, and I got much better performance indeed.

Also, you can improve things a little by converting everything non-DX12 and non-Vulkan with DXVK, this did wonders for me:

We're glad to know the information helped. Hopefully, it will help other community members. Since the thread is now solved, we will close it. If you need any additional information, please submit a new question as this thread will no longer be monitored

Intel does not verify all solutions, including but not limited to any file transfers that may appear in this community. Accordingly, Intel disclaims all express and implied warranties, including without limitation, the implied warranties of merchantability, fitness for a particular purpose, and non-infringement, as well as any warranty arising from course of performance, course of dealing, or usage in trade.

Unfortunately this system has been giving me nothing but trouble since the initial build date of July 2019. Things have been getting particularly bad since the start of 2020 with the symptoms primarily manifesting themselves as daily hard lockups (mainly above 2133 MHz DDR4 speeds) and segfaults (at any DDR4 speed).

When the system locks up I am unable to do anything other than a hard reset via the physical button. No response from: SysReq, CAPS LOCK, CTRL+ALT+F2, CTRL+ALT+BACKSPACE. I have not tried to SSH into the system when it is in this state but I do not imagine it would be responsive if even the keyboard LEDs are not.

In spite of everything I have attempted the system is not stable. Most of these crashes happen at idle and with DDR4 speeds above 2133 MHz. Dropping the RAM speeds to 2133 MHz seems to help with the system locking up (makes it happen once a month instead of every day) but the segfaults still happen. Both attached files from dmesg and journalctl are with DDR4 running at Auto (2133 MHz).

I am really getting to the point where I am running out of things to try so I would greatly appreciate any and all suggestions you may have. I recently attempted to open an RMA with AMD and they were pretty adamant that they do not feel as though any of this is CPU related... but I do not see what else would cause these issues. I also do not feel as though their support bothered to actually read my ticket as all of the questions they asked me to respond to had already been answered in the initial request. I have been running Arch on systems for over 15 years and I have never seen one suffer from this kind of stability issues... which is a real shame because I had high hopes for Ryzen.

Here is a link to dmesg, journalctl, and the message I received from AMD support. The log files are indicative of the segfault issues I am experiencing. When the system hard locks there is no indication of it in the log files.

My GPU is the Gigabyte RX570 Gaming 4G. I was previously experiencing the odd GPU related lockup but I have not seen anything pertaining to that specifically since adding "amdgpu.noretry=0" to the kernel parameters.

I have enabled SSH and will attempt to log into the machine remotely if the lockup happens again. The frequency is sporadic, not easy to reproduce, and it currently has not happened since the 14th (7 days). I am hoping that the issue with the lockups is resolved but in the meantime am still experiencing these segfaults which I do not believe are related to the GPU.

I had seen this post previously, but I do not see the issues as being connected. The poster in the topic you linked to has an easily reproducible error, and one which he claims was fixed with the 5.6.3 Linux kernel (I am running 5.6.5-arch3-1). In fact the only thing that poster and I have in common appear to be our UEFI versions. Even his motherboard is different from mine. Gigabyte X570 UD is not the same as Gigabyte X570 Gaming X (the X570 part is there to indicate the chipset).

IOMMUv2

That thread you linked to was from 2016 when IOMMUv2 was still uncommon for amd non-server processors .

All ryzen / threadripper / epyc aka zen family processors do support it in hardware and only show that message if IOMMU is disabled in firmware.

A disabled IOMMU works fine on 32-bit OSes but can severely hamper functionality on 64-bit OSes.

In fact the only thing that poster and I have in common appear to be our UEFI versions. Even his motherboard is different from mine. Gigabyte X570 UD is not the same as Gigabyte X570 Gaming X (the X570 part is there to indicate the chipset).

Firmware for AMD chipsets is supplied by AMD to motherboard manufacturers in the form of AGESA . The manufacturer usually does some tweaking , testing and adds a few things but the majority of the functionality comes from the agesa version.

The Gigabyte X570 UD and your Gigabyte X570 Gaming X use the same chipset and come from the same manufacturer. There's a very big chance they also use the same AGESA version .

It does look like you have different symptoms though.

After rebooting this morning and making sure IOMMU was enabled (it must have been disabled during the UEFI reset) I am unfortunately still experiencing the segfault issue. I wish it was program specific but I have seen it affect many different applications on this device. Here are my logs from this morning:

I remember seeing one or two people say that the AMD "AGESA 1.0.0.4 B" firmware has issues with something, and that the previous "AGESA 1.0.0.3 ABBA" was somehow better. I didn't see any details. If Gigabyte offers a BIOS with that 1.0.0.3 ABBA thingy on their support site, maybe try that and see what happens. You will have to set all your BIOS settings again if you try a different BIOS (don't load a saved settings profile from a different version).

I think I remember someone say that their 3000 series CPU needs a tiny bit of extra voltage to run stable. There's an "offset voltage" setting that can add (or subtract) from the CPU's core voltage. You would try a value like "+0.025 V" for that kind of setting. Something like "+0.1 V" would be too much, don't try that kind of large value.

On my Ryzen system here, I need "pcie_aspm=off" on the kernel command line. I get strange "machine check errors" when the CPU is under stress without that kernel parameter. This "pcie_aspm=off" is about power saving on the PCIe bus.

I will look into your suggestion regarding downgrading the BIOS and tweaking the offset voltage. I believe I was on version F4 of the UEFI until around January. I only began to flash versions more recent than F4 when the stability issues and hard locks began to present themselves.

It seems like F5b may in fact be the version I should downgrade to based on your suggestions regarding the AGESA versions. I believe I went straight from F4 to F10 (and then on to the F11 when that failed to resolve my issues).

3a8082e126