Are newer ryzen cpu supported? 4750G 5600x?

[0bsidian]

I am making my first build to learn proxmox and some of my top cpu choices are 4750G or 5600X
I could not find any information if these are compatible, only some threads that mention installation & performance issues and that the current kernel 5.4 does not support them because they are so new. Is that true, should I go with something older like 3700X?

 

[Stefan_R]

I believe they should work, we're currently shipping kernel 5.4, which isn't too old yet. I have seen reports of those CPUs working, though of course that also depends on other factors, like mainboard and BIOS support. Other than the kernel there shouldn't be any issues either.

With our next major release we'll switch to (probably) 5.10 which most certainly will support the CPUs you mention. And there is of course always the option of building your own kernel (our git already has 5.10), and there's also some (unsupported!) third-party projects providing pre-built PVE kernels.

That being said, the 3000 series is most certainly supported, that I can guarantee without asterisks.

 

[James Crook]

I am making my first build to learn proxmox and some of my top cpu choices are 4750G or 5600X
I could not find any information if these are compatible, only some threads that mention installation & performance issues and that the current kernel 5.4 does not support them because they are so new. Is that true, should I go with something older like 3700X?

So from my understanding the 4000G are really 3000 chips with Vega graphics in them, and for OEMs.

Do report back on what you go with as i've been waiting to pull the trigger on upgrading my Intel i5 4690K as it's got far too many PCI cards to not cause bottlenecks

 

[0bsidian]

I believe they should work, we're currently shipping kernel 5.4, which isn't too old yet. I have seen reports of those CPUs working, though of course that also depends on other factors, like mainboard and BIOS support. Other than the kernel there shouldn't be any issues either.

With our next major release we'll switch to (probably) 5.10 which most certainly will support the CPUs you mention. And there is of course always the option of building your own kernel (our git already has 5.10), and there's also some (unsupported!) third-party projects providing pre-built PVE kernels.

That being said, the 3000 series is most certainly supported, that I can guarantee without asterisks.

Is there any estimation when to expect 5.10 version? I'm just starting out with no prior experience so a bit skeptical building kernel or using third-party will be smooth for me. This user reports an easy fix for the 4650g APU which should be similar to 4750g's case. If the newer official kernel is around the corner, or if a single command as this users fix suggestion will let me use the 4750g, I might get it. I dont need to passthrough or anything, just use it as is, with the integrated graphics used for hooking up a monitor.

 

[Stefan_R]

No ETAs from our side, but as said the 4000 series should pose no problem (aside from the one in the post you linked).

 

[peteb]

I'm running PVE on a 5950x and the vanilla install with the the most recent iso from proxmox worked well (proxmox-ve_6.3-1.iso).
There is also a dependency on your motherboards bios AGESA version - mine is (ComboV2 to 1.1.0.0).

However after installing I ran a PVE update and it pulled in kernel 5.4.98 (the install used kernel 5.4.73) and I had all sorts of instability issues relating to the kernel and RDRAND and windows machines not showing correct hardware and missing disks. I didn't have the time to work on fixing it so I reinstalled from the iso and everything worked fine. After the install I have not upgraded any packages and everything is fine.

I see Proxmox have now released a newer kernel (5.4.101). But I have not upgraded to it.

 

[Stefan_R]

I had all sorts of instability issues relating to the kernel and RDRAND and windows machines not showing correct hardware and missing disks.

A fix for Windows machines bluescreening on certain AMD configs is included in 5.4.101, the issue with changed hardware configs in Windows guests is related to QEMU 5.2, you can avoid it by not updating that specific package (pve-qemu-kvm) - we're working on a better fix.

The RDRAND issue is new to me, do you have any more info/logs regarding it? I believe we currently don't have a testbench with a 5000 series Ryzen to reproduce anything, but it could still be worthwile to take a closer look (or seeing if 5.4.101 fixes it).

In case you're unaware, you can always downgrade packages as well, without reinstalling, by running 'apt install pve-qemu-kvm=5.1.0-8' (replace package and version with desired ones). Or for kernels simply select an older one at the GRUB menu on boot.

 

[peteb]

A fix for Windows machines bluescreening on certain AMD configs is included in 5.4.101, the issue with changed hardware configs in Windows guests is related to QEMU 5.2, you can avoid it by not updating that specific package (pve-qemu-kvm) - we're working on a better fix.

The RDRAND issue is new to me, do you have any more info/logs regarding it? I believe we currently don't have a testbench with a 5000 series Ryzen to reproduce anything, but it could still be worthwile to take a closer look (or seeing if 5.4.101 fixes it).

In case you're unaware, you can always downgrade packages as well, without reinstalling, by running 'apt install pve-qemu-kvm=5.1.0-8' (replace package and version with desired ones). Or for kernels simply select an older one at the GRUB menu on boot.

Unfortunately I reinstalled pve from the iso and didn't keep any logs.

This thread details the RDRAND issue and the boot parameters needed to disable it: https://forum.proxmox.com/threads/a-lot-of-errors-systemd-kernel-on-newer-hardware.84758/

I'm sure the VM issues were related to QEMU 5.2 as you point out and the instability (with pve services not starting up properly) was probably fixed by setting SYSTEMD_RDRAND=0 in the grub / ZFS boot parameters.

Right now I'm sticking with 5.4.73 kernel and the older ZFS 0.8.5 until I get more time to troubleshoot again.

 

[Ramalama]

Unfortunately I reinstalled pve from the iso and didn't keep any logs.

This thread details the RDRAND issue and the boot parameters needed to disable it: https://forum.proxmox.com/threads/a-lot-of-errors-systemd-kernel-on-newer-hardware.84758/

I'm sure the VM issues were related to QEMU 5.2 as you point out and the instability (with pve services not starting up properly) was probably fixed by setting SYSTEMD_RDRAND=0 in the grub / ZFS boot parameters.

Right now I'm sticking with 5.4.73 kernel and the older ZFS 0.8.5 until I get more time to troubleshoot again.

This thread is made by me, it sounds more worse as it is.

Rdrand issue isn't an issue if your mainboard manufacturer released an bios with newest agesa (1.2.0.0+)
Otherwise you need the cmdline argument.

Most of the other issues comes from to new lxc containers probably.

In general, my proxmox host is an x570+5800x combo with ecc memory.

Everything works perfectly, it's fast as hell, and well, you need to adjust 2-3 things, but that's totally normal.

The only thing that nervs me a little bit, is still the systemd rdrand issue. It works with the cmdline Parameter. But on random boots, you still have 1 or 2 failed services.
Means you have to check your bootlog every time with journalctl -b and restart the failed service, or in hardest case reboot again. And no systemctl --failed doesn't show the failed service, dunno why, thats why you need journalctl -b | grep failed.

But that's something that gets fixed, once asrock rack finally releases an bios with the new agesa.

Once the system is booted, it runs solid and damn fast. And probably for forever xD

So in general, i can fully recommend zen3.
It simply makes no sense even to buy anything else. Only if you want more pcie lanes, you switch to prosumer or server platforms. But other as pcie lanes, there is no reason, because we have ecc with ryzen xD
Ah and for passthrough, i can only speak for the x570d4i, you have pretty perfect separated iommu groups. So that's not a reason for other platforms as well.

Cheers