Some Ryzen Linux Users Are Facing Issues With Heavy Compilation Loads

[Chewi]

Thank you! I've been running extra youtube tabs in firefox with videos constantly playing for almost a month now just to prevent those.

Please report back if it works. I haven't had anyone else confirm it yet.

[ramrod]

Affirmative.
(damn character limit...)

Thank you! I've been running extra youtube tabs in firefox with videos constantly playing for almost a month now just to prevent those.

[Chewi]

Does this fix the freeze that happens when the system is idle?

Affirmative.
(damn character limit...)

[ramrod]

I've managed to fix my freezes. Turns out it was CONFIG_RCU_NOCB_CPU and CONFIG_RCU_NOCB_CPU_ALL. These are enabled in Fedora. After enabling just these in my minimal config, there was no freeze. After disabling these in Fedora's config, I got a freeze. I don't know the reasoning but it seems quite conclusive. I don't yet know whether it's merely a workaround for some underlying issue or even whether it simply makes a freeze less likely. What's the best way to get this information across to AMD? @bridgman?

Interestingly, CONFIG_RCU_NOCB_CPU is not enabled in Debian. We haven't seen swarms of Debian users reporting freezes with Ryzen so perhaps this issue is specific to the motherboard or some other factor. I did want to try a prebuilt Debian kernel but I was surprised that I couldn't find anything newer than 4.10, even among Ubuntu, Mint, and Sid.

I previously said that I hadn't seen any segfaults. I did see some eventually but disabling ASLR fixed it. I am now booting with norandmaps to ensure that ASLR is disabled immediately on boot. Enabling CONFIG_COMPAT_BRK in the kernel doesn't actually disable ASLR entirely.

Does this fix the freeze that happens when the system is idle?

[Chewi]

I've managed to fix my freezes. Turns out it was CONFIG_RCU_NOCB_CPU and CONFIG_RCU_NOCB_CPU_ALL. These are enabled in Fedora. After enabling just these in my minimal config, there was no freeze. After disabling these in Fedora's config, I got a freeze. I don't know the reasoning but it seems quite conclusive. I don't yet know whether it's merely a workaround for some underlying issue or even whether it simply makes a freeze less likely. What's the best way to get this information across to AMD? @bridgman?

Interestingly, CONFIG_RCU_NOCB_CPU is not enabled in Debian. We haven't seen swarms of Debian users reporting freezes with Ryzen so perhaps this issue is specific to the motherboard or some other factor. I did want to try a prebuilt Debian kernel but I was surprised that I couldn't find anything newer than 4.10, even among Ubuntu, Mint, and Sid.

I previously said that I hadn't seen any segfaults. I did see some eventually but disabling ASLR fixed it. I am now booting with norandmaps to ensure that ASLR is disabled immediately on boot. Enabling CONFIG_COMPAT_BRK in the kernel doesn't actually disable ASLR entirely.

[PuckPoltergeist]

Not necessarily, because the higher tick rate might deliver information that completes a task several milliseconds sooner.

Doesn't affect the performance of the system. Yes, one task may finish more early, but the throughput of the whole system is more with less task switches.

[PuckPoltergeist]

With Ryzen maybe slowing down the kernel would make it stable. Phoronix uses Debian/ubuntu 250Hz timer kernel and Gentoo 1000Hz timer kernel.

It's the other way around, lower resolution speeds up the system (and the kernel, that is part of the system).

[alfonsor]

With Ryzen maybe slowing down the kernel would make it stable. Phoronix uses Debian/ubuntu 250Hz timer kernel and Gentoo 1000Hz timer kernel. There are plenty of kernel config options that affects stability like with RX460 and the amdgpu kernel driver, Virtualization and KVM must be enabled.

tries 250, same segfault in bash

it's a curse

[Beherit]

Still no fix from AMD for this. Their last official post about this is more than a week old now, where they urge users to try out disabling OPCache Control and SMT. That and all other reported "fixes" so far, make crashes less frequent. Even though many report significant improvements, crashes still occur. So the main issue remains...

I certainly hope AMD is still working on this and not just silently praying that the workarounds are "good enough" for forum chatter to die.

Kudos to Matt dillon and his AMD CPU hacking skillz, I didn't know he's uncovered other fatal hardware bugs in the past: http://techreport.com/news/22586/bsd...amd-processors

[nils_]

I don't see why I should mess with that stuff when simply changing the kernel configuration stops the freezing.

You're disabling a security feature to work round broken hardware...