4 ms·

It seems to happen on heavily overclocked CPUs. Phoronix user had managed to replicate the issue he wasn't experiencing by simply pushing it a bit further.

by c2h5oh 9y ago

bnolsen 9y ago
Always had problems with this in the old days with intel stuff when I used to overclock. There's a reason I don't overclock anymore...
dom0 9y ago
Tickets from users using overclocked components are generally INVALID CLOSED.
dryatu 9y ago
Not exclusively on overclocked CPUs. segfaults happen even with factory defaults.
- c2h5oh 9y ago
  Interesting. With what AGESA version - I'm asking because anything earlier than 1.0.0.6 has 1T command rate, which not all memory modules can handle
  - aidenn0 9y ago
    Is there an easy way to check my AGESA version? I'm on the latest BIOS revision for my motherboard and I still saw these symptoms.
examancer 9y ago
There are multiple examples of people who are not overclocking at all and have gone to great lengths to ensure everything in their BIOS was properly configured. There does seem to be a real issue here. My money is on memory controller and issues with certain DDR4 modules. Hopefully something AMD can sort out with BIOS updates.
deleted 9y ago
[deleted]
hatsunearu 9y ago
Yeah, overclocking tends to fuck up certain corner cases--my friends once told me when you're debugging with a debugger you should turn off overclocking because that could really fuck up how the debugger works
aidenn0 9y ago
I run a 100% stock clock Ryzen 1700 with the most recent bios. It happened for me very reliably after ~45 minutes of compiling. It was nearly always a segfault in bash (and most of the time bash was running libtool). CPU temperatures were in the upper 50s; downright cold compared to the rather hot (and old) Xeon CPU it replaced. Interestingly enough, and I'm not the only one to report this, rebuilding the entire system with GCC 6.3 caused the problems to go away (I'm running Gentoo, so this was quite feasible). This is really odd because I was not using any AMD specific cflags, just the default x64 march. I'm guessing the problem didn't actually go away, but rather the instruction scheduling of GCC 6.3 is less likely to cause whatever the underlying problem was.

It seems to happen on heavily overclocked CPUs. Phoronix user had managed to replicate the issue he wasn't experiencing by simply pushing it a bit further.

by c2h5oh 9y ago

It seems to happen on heavily overclocked CPUs. Phoronix user had managed to replicate the issue he wasn't experiencing by simply pushing it a bit further.

bnolsen 9y ago

Always had problems with this in the old days with intel stuff when I used to overclock. There's a reason I don't overclock anymore...

dom0 9y ago

Tickets from users using overclocked components are generally INVALID CLOSED.

dryatu 9y ago

Not exclusively on overclocked CPUs. segfaults happen even with factory defaults.

c2h5oh 9y ago
Interesting. With what AGESA version - I'm asking because anything earlier than 1.0.0.6 has 1T command rate, which not all memory modules can handle
- aidenn0 9y ago
  Is there an easy way to check my AGESA version? I'm on the latest BIOS revision for my motherboard and I still saw these symptoms.

examancer 9y ago

There are multiple examples of people who are not overclocking at all and have gone to great lengths to ensure everything in their BIOS was properly configured. There does seem to be a real issue here. My money is on memory controller and issues with certain DDR4 modules. Hopefully something AMD can sort out with BIOS updates.

deleted 9y ago

[deleted]

hatsunearu 9y ago

Yeah, overclocking tends to fuck up certain corner cases--my friends once told me when you're debugging with a debugger you should turn off overclocking because that could really fuck up how the debugger works

aidenn0 9y ago

I run a 100% stock clock Ryzen 1700 with the most recent bios. It happened for me very reliably after ~45 minutes of compiling. It was nearly always a segfault in bash (and most of the time bash was running libtool). CPU temperatures were in the upper 50s; downright cold compared to the rather hot (and old) Xeon CPU it replaced. Interestingly enough, and I'm not the only one to report this, rebuilding the entire system with GCC 6.3 caused the problems to go away (I'm running Gentoo, so this was quite feasible). This is really odd because I was not using any AMD specific cflags, just the default x64 march. I'm guessing the problem didn't actually go away, but rather the instruction scheduling of GCC 6.3 is less likely to cause whatever the underlying problem was.