Announcement

Collapse
No announcement yet.

Some Ryzen Linux Users Are Facing Issues With Heavy Compilation Loads

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Originally posted by tg-- View Post
    Ryzen 1800X @ 3.9 GHz overclock, stock voltage
    ASUS Prime X370 Pro
    Kingston 2133 MT ECC Ram running at 2666 MT currently (only possible with AGESA 1.0.0.6)

    So I can't confirm any of the issues. When I'm raising the clock to 3.95 GHz I'm seeing uops-cache ECC failures. When I raise ram clock beyond 1333 MHz, I'm seeing RAM ECC errors.
    Crashes under heavy load appear at 4 GHz, halts due to excessive ECC failures appear under heavy load at abote 2666 MT.

    Clearly doesn't seem to be a general problem, though hardware may be faulty for some people. Not for me.
    I wouldn't trust 3.9GHz if 4GHz crashes.

    Comment


    • Originally posted by atomsymbol View Post
      Have you tried disabling the boost frequency, checking that Vcore is 1.2 Volts, and lowering operating frequency below the default frequency (for example: 3.0GHz in case the default frequency is 3.2GHz (Ryzen 5 1600))?
      I don't see why I should mess with that stuff when simply changing the kernel configuration stops the freezing.

      Comment


      • Originally posted by brent View Post
        As for Intel being the "safe" choice, note that Intel also had serious stability issues with Skylake and with Haswell they had to disable the TSX feature because it was broken. (How did they ever get away with this? They permanently disabled a feature that the CPU was advertised with!)
        I was really surprised there was no class-action lawsuit about this. Although I don't know if TSX is also broken in Skylake, it was broken in Broadwell (not Broadwell E though). But compared to the AMD problem the TSX problem is hard to trigger.

        Comment


        • Originally posted by Chewi View Post
          I don't see why I should mess with that stuff when simply changing the kernel configuration stops the freezing.
          I agree, but it may be the case that the kernel configuration just lowers the probability of crashes rather than actually removing the cause of the crashes.

          ----

          Some years ago, I had an Athlon XP CPU that was rated to run at frequency 1800 MHz (if I remember correctly) but it was unstable and so had to downclock it by one speed grade to make it run stable. Considering decades of time, Intel CPUs are facing such issues less frequently - but I don't have concrete statistics on this, so I may be wrong - Intel Celeron Mendocino and other Intel CPUs I was using years ago were running reliably.

          Comment


          • I've found that on my Ryzen R7 1700X running on an MSI B350M Mortar mainboard the segfaults during compilation happen much more frequent with gcc-4.9.4 than with gcc-6.3.0, so if some AMD engineers want to reproduce them for debugging purposes, I'd recommend to use that older gcc version.

            Comment


            • Originally posted by Chewi View Post

              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...

              Comment


              • 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

                Comment


                • Originally posted by debianxfce View Post
                  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

                  Comment


                  • Originally posted by debianxfce View Post
                    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).

                    Comment


                    • Originally posted by PuckPoltergeist View Post
                      It's the other way around, lower resolution speeds up the system (and the kernel, that is part of the system).
                      Not necessarily, because the higher tick rate might deliver information that completes a task several milliseconds sooner.

                      Comment

                      Working...
                      X