TR Forums

I bought a Ryzen CPU intending to use it for both Windows 7 and Linux. Foolishly (for I should know better), I didn't check first whether my distribution supported Ryzen.

I knew I'd have problems installing Windows 7. When trying my installation DVD, neither the keyboard nor the mouse worked, so I couldn't progress. Fortunately, my motherboard manufacturer (Gigabyte) prepared a patch for a boot USB drive, and after applying the patch, installation was no problem.

I also knew that Microsoft deliberately broke Windows update on Windows 7 with Ryzen (this sounds like an abuse of a dominant position to me), but I also knew there was a patch for that also.

Linux was a much bigger problem. I couldn't get Grub to install properly, even though I literally wrote the book (well, a book) on installing Grub. Finally I discovered my problem: my version of Linux didn't support Ryzen.

I'm using CentOS 6, and I'd be more than willing to accept the clear message that I should switch to CentOS 7, but apparently that also doesn't work.

Phoronix tried seven distributions with Ryzen, and CentOS was the only one that didn't work. I've always been curious about Debian; now may be the right time to try it.

You would be well advised to use the latest versions of whatever distro you are using, and update to the latest kernel as well.

Wow, so a distro that uses old kernels and is pretty slow in bringing patches in for new hardware to an old kernel.. didn't work?

Surprise.

Use Slackware, FC, Gentoo, Arch, or basically anything but CentOS/RHEL. For so many reasons. Especially on new hardware.

In the RH world, I'd expect Fedora 26 Beta might be okay but RHEL and derivatives not so much. Is there a CentOS 7.4 beta branch you can try?

Yan wrote:

I bought a Ryzen CPU intending to use it for both Windows 7 and Linux. Foolishly (for I should know better), I didn't check first whether my distribution supported Ryzen.
Finally I discovered my problem: my version of Linux didn't support Ryzen.

For what it's worth, I use Mint 16.04 and it worked nicely with the stock kernel, although I had already compiled manually the latest stable kernel version with Ryzen support. I did have to recompile a bunch of other stuff that was installed from source because as you may have noticed, Ryzen does not support all the instructions that Bulldozer does.

If your only problem is kernel support you could simply compile and install your own version, but if the whole system has been compiled with the wrong flags you will have to install another distribution. Debian-based distributions work fine.

Debian (and its derivatives) generally try to be broadly compatible out-of-the-box. Off the top of my head, the only compatibility issues I've had when installing Ubuntu have been related to GPU support (GPU drivers can be a bit of a clusterf*ck on any distro if you get unlucky), and my first attempt at booting from a software RAID volume on an EFI motherboard (a multi-evening adventure which eventually ended successfully).

To be completely honest, why anyone would even *think* of adopting RyZen before approximately six months has passed since its release is beyond me.

And I'm saying this as someone who is rooting for AMD to succeed and tend to buy AMD for their fairly reasonable (read: not-totally-bullcrap like intel) approach to market segmentation for consumer vs. enterprise hardware.

just brew it! wrote:

Debian (and its derivatives) generally try to be broadly compatible out-of-the-box. Off the top of my head, the only compatibility issues I've had when installing Ubuntu have been related to GPU support (GPU drivers can be a bit of a clusterf*ck on any distro if you get unlucky), and my first attempt at booting from a software RAID volume on an EFI motherboard (a multi-evening adventure which eventually ended successfully).

I can't speak for RAID since I never used it, but back when you had to install any proprietary drivers and other stuff yourself, it was a PITA due to having to manually set it up. When you update the kernel/system you also had to do that all over again. I'm glad those days are gone(well depending on which distro you are using).

whm1974 wrote:

just brew it! wrote:

Debian (and its derivatives) generally try to be broadly compatible out-of-the-box. Off the top of my head, the only compatibility issues I've had when installing Ubuntu have been related to GPU support (GPU drivers can be a bit of a clusterf*ck on any distro if you get unlucky), and my first attempt at booting from a software RAID volume on an EFI motherboard (a multi-evening adventure which eventually ended successfully).

I can't speak for RAID since I never used it, but back when you had to install any proprietary drivers and other stuff yourself, it was a PITA due to having to manually set it up. When you update the kernel/system you also had to do that all over again. I'm glad those days are gone(well depending on which distro you are using).

I've still had one (relatively) recent case where Ubuntu defaulted to a broken driver (Noveau) for an NVIDIA card, causing the system to crash on startup. IIRC I had to force it to boot in framebuffer mode and install the binary driver via CLI.

just brew it! wrote:

whm1974 wrote:

just brew it! wrote:

Debian (and its derivatives) generally try to be broadly compatible out-of-the-box. Off the top of my head, the only compatibility issues I've had when installing Ubuntu have been related to GPU support (GPU drivers can be a bit of a clusterf*ck on any distro if you get unlucky), and my first attempt at booting from a software RAID volume on an EFI motherboard (a multi-evening adventure which eventually ended successfully).

I can't speak for RAID since I never used it, but back when you had to install any proprietary drivers and other stuff yourself, it was a PITA due to having to manually set it up. When you update the kernel/system you also had to do that all over again. I'm glad those days are gone(well depending on which distro you are using).

I've still had one (relatively) recent case where Ubuntu defaulted to a broken driver (Noveau) for an NVIDIA card, causing the system to crash on startup. IIRC I had to force it to boot in framebuffer mode and install the binary driver via CLI.

The last time I had to deal with using framebuffer mode in Linux was with Mandriva when I had to boot into that mode in order to watch movies from my VCR using my Nvidia based card with S-Video input. This was before GRUB.

RHEL/CentOS 6/7 will have patches available for Ryzen once Naples/Epyc actually launches and is in the hands of sysadmins. Hopefully prior to the actual launch of Epyc, though.

I started out dabbling with Redhat about a decade and a half ago, and used a hacked up Debian as the basis for an embedded device at work. Didn't really consider Linux for desktop use until I tried Ubuntu 8.04 though; and by around 2011 it was my primary desktop OS.

I'm pretty much equally comfortable with (K)Ubuntu or Debian these days. They're almost identical under the hood.

Update: I was able to run CentOS 6 under Ryzen after all. Information here and here.

So a false alarm, it would seem. (Phoronix's issues with Centos 7 notwithstanding.)

I was wondering if anyone could help clarify how serious and pervasive (ie, how many users might be affected) by the purported Linux heavy load/compilation bug, as explained here:

It’s been reported that sporadic segmentation faults were occurred on Linux/Ryzen under heavy CPU loads especially during parallel-compiling large OpenSource code such as Linux kernel, Mesa, LLVM, Chromium and WebKit.

I don't have any experience compiling programs or kernels in Linux, so I'm not trying to grock a low level understanding of the issue. Just, basically how serious this might be for the adoption of Threadripper/EPYC. Do /would more than a very miniscule proportion of users actually do heavy load compiling in Linux? Any thoughts on the likelihood of a microcode fix if it hasn't been fixed so far?

It hasn't been fixed, and it's serious in the sense that if you do something like on your systems regularly, you're not going to buy a ryzen system.

Linux was a much bigger problem. I couldn't get Grub to install properly, even though I literally wrote the book (well, a book) on installing Grub. Finally I discovered my problem: my version of Linux didn't support Ryzen.

Sounds like an abuse of dominant position to me. You should totally report the CenOS project to your state's attorney general. How dare they not backport Ryzen patches, fixes, and drivers to old kernels.

/s

just brew it! wrote:

Off the top of my head, the only compatibility issues I've had when installing Ubuntu have been related to GPU support (GPU drivers can be a bit of a clusterf*ck on any distro if you get unlucky), and my first attempt at booting from a software RAID volume on an EFI motherboard (a multi-evening adventure which eventually ended successfully).

JBI, how DID you get that working? I'm in a similar situation myself (fortunately not urgent so the hardware is off for now). I'm aware that you're supposed to use software/OS-level RAID for Linux, but it's a complete mystery to me how to get that working with a boot drive.

Documentation said "Install GRUB2 on all disks separately", which sounds insane but I did do that, to no effect (FakeRAID and Software RAID both won't boot).

EDIT: The strange thing is that Mint 17.0 doesn't mind FakeRAID or Software RAID at all, if I use a LiveCD everything is seen properly - the only problem seems to be booting it.

cynan wrote:

I don't have any experience compiling programs or kernels in Linux, so I'm not trying to grock a low level understanding of the issue. Just, basically how serious this might be for the adoption of Threadripper/EPYC. Do /would more than a very miniscule proportion of users actually do heavy load compiling in Linux? Any thoughts on the likelihood of a microcode fix if it hasn't been fixed so far?

Glorious wrote:

It hasn't been fixed, and it's serious in the sense that if you do something like on your systems regularly, you're not going to buy a ryzen system.

Yup, this is one of the reasons I am in no hurry to jump on Ryzen. Until there's at least a better understanding of what triggers the issue, there's no guarantee that you won't be affected. And I do occasionally run large compiles.

The other disturbing aspect to this issue is that gcc isn't a particularly "special" application. Yet it seems to be hitting some weird corner case that trips Ryzen up. Until we understand what that corner case is, there's no guarantee that other CPU-intensive workloads are completely immune.

Vhalidictes wrote:

just brew it! wrote:

Off the top of my head, the only compatibility issues I've had when installing Ubuntu have been related to GPU support (GPU drivers can be a bit of a clusterf*ck on any distro if you get unlucky), and my first attempt at booting from a software RAID volume on an EFI motherboard (a multi-evening adventure which eventually ended successfully).

JBI, how DID you get that working? I'm in a similar situation myself (fortunately not urgent so the hardware is off for now). I'm aware that you're supposed to use software/OS-level RAID for Linux, but it's a complete mystery to me how to get that working with a boot drive.

Documentation said "Install GRUB2 on all disks separately", which sounds insane but I did do that, to no effect (FakeRAID and Software RAID both won't boot).

EDIT: The strange thing is that Mint 17.0 doesn't mind FakeRAID or Software RAID at all, if I use a LiveCD everything is seen properly - the only problem seems to be booting it.

I'll have to dig up my notes. Yes, installing GRUB multiple times was part of it. IIRC I ended up manually cloning the EFI partition as well, and you need to manually run update-initramfs after properly configuring your mdadm.conf file to make sure the RAID volume is visible during boot. I believe it was picky about partition types too (not just the filesystem formats, but the partition type codes recorded in the partition tables).

Geez whiz even though I want a cheap six or eight core system, with of these problems Ryzen is having with Linux I think I would stick with Intel if I was building a new rig. Intel may cost an arm and leg but at least Linux is fully supported and just works.

whm1974 wrote:

Geez whiz even though I want a cheap six or eight core system, with of these problems Ryzen is having with Linux I think I would stick with Intel if I was building a new rig. Intel may cost an arm and leg but at least Linux is fully supported and just works.

New processors hardware components are supported when they are supported, if a Linux distro (or Windows release) is too old to support a new thing, that's that. New Intel CPUs often may not work well with older distros, I remember many issues people have had trying to run on non-supported hardware going back to at least Pentium 4 / 850 and Pentium D / 875 (?), not playing well with Linux.

And wanting a cheap 6-8 core CPU is different from needing one, or from buying one. Crappy old cheapo AMD ones are $90 on Newegg, Linux is fully supported; really good AMD ones are $215, Linux support will take a little while -- yet decent Intel starts at $350. Is e.g. a $135 better GPU worth a bit of fiddling around, to a computer nerd?

Certainly seems to be a bit of a corner case all right. Some report less/no segfaults with later versions of GCC. And it seems that some versions of Linux are more susceptible (Gentoo seems to be the most?). Others claim that bumping up MB voltages seem to reduce the occurrence (which seem to be a system stability issue - which doesn't necessarily get RyZen off of the hook as it could just as likely be that some are simply passing validation when they shouldn't, or are clocked too high stock, rather than a MB/Power supply issue). Still others are conflating segfaults with full lockups... And it seems like this issue is less pervasive on RyZen 5?

I guess the fact that it is taking so long to track the route of this down might suggest that there aren't really that many people compiling using GCC with RyZen? But whether that's because that is a relatively small bunch of users, or that they are actively avoiding RyZen for this very reason, or both...

whm1974 wrote:

Geez whiz even though I want a cheap six or eight core system, with of these problems Ryzen is having with Linux I think I would stick with Intel if I was building a new rig. Intel may cost an arm and leg but at least Linux is fully supported and just works.

Well, the problem reported in the OP was specific to an old version of CentOS so that's really a non-issue unless you have a requirement to run that specific version of CentOS, and are unwilling/unable to follow the workaround which was linked further down the thread.

It is also possible that the parallel gcc problem may be a symptom of something that, at its core, isn't actually specific to Linux (or gcc). Parallel gcc compiles on Linux may just be very good at hitting whatever corner case triggers the issue.

We've got more info on the bug these days, and it sounds bad (but I don't remember where I saw it and don't remember enough detail to credibly talk about it much myself). Looks like it causes a microcode hang when threads on the same core try to do certain things. It definitely isn't just GCC-related. I trust that AMD has put whatever resources they can towards fixing this, because in it's current state, EPYC would be DOA. Microcode being implicated implies that it is fixable, but the time already taken implies that it's a bit of a messy fix. The fallback fix that people like us can implement in the meantime is to disable SMT.

I'll buy it regardless. 8C8T AMD is still both cheaper and at least as fast as 4C8T Intel at the workloads I'm most interested in, and SMT (if/when it's usable) is just icing on the cake.

Topinio wrote:

whm1974 wrote:

Geez whiz even though I want a cheap six or eight core system, with of these problems Ryzen is having with Linux I think I would stick with Intel if I was building a new rig. Intel may cost an arm and leg but at least Linux is fully supported and just works.

New processors hardware components are supported when they are supported, if a Linux distro (or Windows release) is too old to support a new thing, that's that. New Intel CPUs often may not work well with older distros, I remember many issues people have had trying to run on non-supported hardware going back to at least Pentium 4 / 850 and Pentium D / 875 (?), not playing well with Linux.

And wanting a cheap 6-8 core CPU is different from needing one, or from buying one. Crappy old cheapo AMD ones are $90 on Newegg, Linux is fully supported; really good AMD ones are $215, Linux support will take a little while -- yet decent Intel starts at $350. Is e.g. a $135 better GPU worth a bit of fiddling around, to a computer nerd?

Well I for one tend to also upgrade my OS at the time as I do new builds anyway. And yes I rather buy a Ryzen over the older Bulldozer and Piledriver CPUs.

whm1974 wrote:

Geez whiz even though I want a cheap six or eight core system, with of these problems Ryzen is having with Linux I think I would stick with Intel if I was building a new rig. Intel may cost an arm and leg but at least Linux is fully supported and just works.

I've had more trouble with Intel systems than you can imagine; PowerVR is one of those things that just never worked right, and if you had one of the CPUs that used that technology you had no paddle.

synthtel2 wrote:

We've got more info on the bug these days, and it sounds bad (but I don't remember where I saw it and don't remember enough detail to credibly talk about it much myself). Looks like it causes a microcode hang when threads on the same core try to do certain things. It definitely isn't just GCC-related. I trust that AMD has put whatever resources they can towards fixing this, because in it's current state, EPYC would be DOA. Microcode being implicated implies that it is fixable, but the time already taken implies that it's a bit of a messy fix. The fallback fix that people like us can implement in the meantime is to disable SMT.

I'll buy it regardless. 8C8T AMD is still both cheaper and at least as fast as 4C8T Intel at the workloads I'm most interested in, and SMT (if/when it's usable) is just icing on the cake.

ouch, I often do parallel builds with GCC, Clang and QEMU on Linux (mainly Fedora). This is not inspiring me to take AMD off my avoid list.

Vhalidictes wrote:

whm1974 wrote:

Geez whiz even though I want a cheap six or eight core system, with of these problems Ryzen is having with Linux I think I would stick with Intel if I was building a new rig. Intel may cost an arm and leg but at least Linux is fully supported and just works.

I've had more trouble with Intel systems than you can imagine; PowerVR is one of those things that just never worked right, and if you had one of the CPUs that used that technology you had no paddle.

PowerVR anything seems to be a pain point with ARM and Intel based systems. I've never had these particular chips so my Intel experiences have been as smooth as silk (so far, touch wood etc).

Vhalidictes wrote:

whm1974 wrote:

Geez whiz even though I want a cheap six or eight core system, with of these problems Ryzen is having with Linux I think I would stick with Intel if I was building a new rig. Intel may cost an arm and leg but at least Linux is fully supported and just works.

I've had more trouble with Intel systems than you can imagine; PowerVR is one of those things that just never worked right, and if you had one of the CPUs that used that technology you had no paddle.

Yeah but are not those CPUs or SoC EOL at this point? AFAIK Intel quit using PowerVR IP in their products.

srg86 wrote:

ouch, I often do parallel builds with GCC, Clang and QEMU on Linux (mainly Fedora). This is not inspiring me to take AMD off my avoid list.

SMT is extremely difficult to get right, and this being AMD's first SMT design, I'll give it a free pass (as far as their reputation). If there were ever a point at which I would expect bugs, a manufacturer's first SMT design would be it. Aside from that, CPUs have bugs quite often - the Haswell TSX bug caused me countless segfaults before I figured out I'd forgotten microcode updates, and Intel only just had an SMT bug of their own.

Now if SMT weren't easy to disable, that would be a real problem (and terribly stupid for exactly this reason).

whm1974 wrote:

Yeah but are not those CPUs or SoC EOL at this point? AFAIK Intel quit using PowerVR IP in their products.

Lincroft and Silverthorne, yes, but I don't believe Cedarview is.