No announcement yet.

Some Ryzen Linux Users Are Facing Issues With Heavy Compilation Loads

  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    Bloody overclocking, never was stable One need to have perfect match of components plus luck for that to work

    I remember Athlon XP 2200+ 14-15 years ago as soon as so you i tried to overclock it a bit everything else was stable, various other burners does not show an issue, but just GCC starts segfaulting Since then i always think GCC is best tool to test OC stability
    Last edited by dungeon; 02 June 2017, 08:26 PM.


    • #32
      Originally posted by pheldens View Post
      I had this issue on ASUS AM1M-A with AMD Athlon(tm) 5150 APU with Radeon(tm) R3

      turned out to be a ram or ram combination issue (if I underclock the ram on default it works ok, on built in ram overclock profile it gets unstable under severe load)
      Ah, i have same mobo just Athlon 5350 and never... it is actually slightly FSB OCed to 2200 MHz and memory also of course about for 3 years now, never an issue.

      But could be mem modules as always , i have there i think Kingston HyperX.

      You know what i am doing, whatever most people recommends i actually buy something else... if most people say buy samsung mem i buy hynix instead and all is fine
      Last edited by dungeon; 02 June 2017, 08:42 PM.


      • #33
        How many of these people are using ECC RAM?

        Long ago, I decided my time is too valuable to waste on debugging problems caused by bad RAM. Since then, I only use ECC in any machine that caches, stores, creates, or modifies any data I don't want to lose.

        If you're not using ECC RAM, at least run memtest overnight. When I can't use ECC, such as in my laptop, I buy quality memory specified to run at a higher speed than my CPU supports. Before use & at any sign of instability, I memtest it overnight. Also, try to limit yourself to one DIMM per channel (unless registered/buffered).

        Aside from bad RAM, noisy power from sketchy PSUs can also be a source of instability. As with RAM, time & energy are too precious to waste on crap PSUs.

        P.S. I regard overclocking as nothing less than begging for instability & shortened component life, and gambling with filesystem & data corruption. It's not worth the risk on anything but a pure gaming machine.
        Senior Member
        Last edited by coder; 02 June 2017, 09:24 PM.


        • #34
          Originally posted by Alliancemd View Post
          At work (...) all were with Intel processors, so I recommended AMD processors (...).
          The IT guys came with a negative response (...)That would of been a bad decision...
          You've just described the problem with most medium/large corporations. There used to be a marketing campaign "No one ever got fired for buying IBM". That was their actual sales pitch. And it worked.

          So say you go with IBM, pay 10-20x more (I'm not talking hardware, but outsourcing, which is how IBM really makes money), and it doesn't work, you can say "Look, I went with big blue, it's not MY fault".

          I really don't mean to rant on you particularly, it's just something I continuously notice in big business.

          It wouldn't have been a bad decision, it would have been taking a risk, that might or might not have paid of. Always playing it safe is not a strategy.


          • #35
            Hi, gentoo user with the problem here.

            The problem consists in segafults during make with problem in bash in the 99% of the cases and segfaults in gcc itself for the remaining 1%

            My machine is brand new; I tried 4 MBs, actually I have a Gigabyte k7, a ryzen 1600, I tried 3 different ram kits and I use a very brand new rm650i as psu, I bought it exactly "just in case".

            In Windows I can run prime95 for hours with no problems. CPU temp rises to 52 C, so I think under heavy compilation in linux It is not a problem (I have an old Thermaltake true spirit in use),

            No overclocking here; I touched BIOS options only to try to solve the problem, with no success. The only option that seems to alleviate it is LLC set to "high". With "alleviate" I mean that during "emerge -e @world" the compilation of 1200 packages is interrupted by "only" 5-10 segfaults and not 15-25.

            Gentoo is compiled with no optimization options, f.e. gcc options are just "-O2 -pipe".

            So, the problem could be a faulty CPU that should be RMAed; I opened a ticked and I am waiting for AMD to tell me so.


            • #36
              I've been running Gentoo with my 1800X just fine. I could compile all day without any problem. But then I've been using stock clocks. I'm positive, that this is only a "not knowing what get are doing" - problem.


              • #37
                AMD Linux

                Running at stock speed with lowered ram timing is certainly a good idea.

                But i really think that AMD more offen than Intel sells Banana ware. In this case problems with XMP RAM - and this CPU's main audience are gamers who buy those chips. But you can not say that the professional use with lots of VMs was tested better: what so you think about the VME-bug? Too much time spent to search competitive gaming benchmarks...


                • #38
                  If this is truly a hardware issue, wouldn't users compiling on other OS' be reporting this as well? Such as Visual Studio on Windows or LLVM on *BSD?


                  • #39
                    Originally posted by bridgman View Post
                    OK, maybe I'm being naive here, but if someone was running a system with overclock and having any kind of stability problems I figured the first thing they would do is run at stock clocks for a while to ensure the problem still happened before thinking there was a problem...

                    ...even typing that I feel like someone is snickering

                    My initial impression is that most (but not all) of the people seeing problems are running Gentoo - is that the impression that others are getting as well ?
                    I think overclocking is only performed by a tiny (and very vocal) fraction of users.

                    The problem may be exposed by Gentoo because compiling stuff is one of the main maintenance tasks, and a 16core cpu is ideally suited for this. The GCC people have a Ryzen Box in the compile farm, and have seen similar issues as well: random segfaults out of the blue that don't even make sense when analyzed.
                    And I've seen random process hangs as well: processes simply get stuck, cpu load drops to zero. The processes can be killed and when restarted they finish.
                    Senior Member
                    Last edited by mlau; 03 June 2017, 03:38 AM.


                    • #40
                      I want to clear up a WHOLE LOT of misconceptions, as this thread (and a few others I've read) is filled with them.

                      AMD Ryzen 7 1700
                      ASRock Fatal1ty X370 Professional Gaming (top end ASRock motherboard)
                      G.Skill F4-3000C15-8GVR (Samsung D-Die memory, dual rank)

                      First off, I have started from a verified (PGP sigs verified even) Gentoo live DVD.
                      I installed fresh from the latest stage3 tarball, so no leftover binutils/GCC from any previous build.

                      I did not recompile bash, or anything that bash is linked against (libreadline, ncurses, and of course, glibc).

                      I'm invoking GCC with '-march=haswell' but do bear in mind, I'm NOT executing any code that GCC spits out until AFTER the ebuild has been installed.
                      I've also tried '-march=nocona' (the AMD64 march that uses the least CPU extensions), and that doesn't help either.

                      Originally posted by sandy8925 View Post
                      Sounds more like a bug in GCC Ryzen code?
                      Well, actually no, it must be something else:
                      [  698.706329] sh[27806]: segfault at 7fa80d8ae8c0 ip 00007fa80d608a90 sp 00007ffc9a4a40c8 error 4 in[7fa80d58f000+190000]
                      [  746.927644] sh[3403]: segfault at 7f27fd2338c0 ip 00007f27fcf8da90 sp 00007fffe10d9a88 error 4 in[7f27fcf14000+190000]
                      The segfaults from what I saw in the gentoo thread, and on my own machine are typically from /bin/sh (symlink to /bin/bash).
                      [email protected] ~ $ ls -li /bin/*sh
                      454 -rwxr-xr-x 1 root root 721520 Apr 19 21:43 /bin/bash
                      456 lrwxrwxrwx 1 root root      4 Apr 19 21:43 /bin/rbash -> bash
                      423 lrwxrwxrwx 1 root root      4 Apr 19 21:43 /bin/sh -> bash
                      The bourne (again) shell is being invoked because of the libtool shell script in this case.

                      Originally posted by doragasu View Post
                      Overheat problem? Segfaults and random freezes under heavy load have always been typical problems that appear on non properly cooled CPUs. Maybe these chips require better cooling than expected.
                      Not a problem for me, my cooler keeps the CPU at around 55 C under both linpack and mprime/prime95.

                      Originally posted by ernstp View Post
                      It's just unstable overclocking...
                      I'm at stock settings, I even verified that the memory timings matched SPD from in windows.
                      I even tried running with max LLC with 1.375 vcore and 1.0v SOC at stock frequencies to no avail.

                      Originally posted by coder View Post
                      Aside from bad RAM, noisy power from sketchy PSUs can also be a source of instability. As with RAM, time & energy are too precious to waste on crap PSUs.
                      I've run memtest86+/HCI memtest for several nights while overclocked and at stock.
                      I'm using a 650 watt seasonic that was used without problems in other machines that draw even more power than my ryzen build.

                      I hope that this wall of text will quell any further misguided statements or conjecture.