AMD Confirms Linux Performance Marginality Problem Affecting Some, Doesn't Affect Epyc / TR

[bridgman]

Do bridgman have an info to share with the forum for whether there is a CPU microcode update that fixes the problem?

I am not aware of a microcode update (or AGESA update in general) which addresses the segfault issue.

There are other issues being fixed in each new update though.

[haagch]

Did you try the AGESA 1.0.0.6B Bios?

No. I have the update installed but I did not try whether it's still happening. But I have seen the other thread where people said they still have it with 1.0.0.6b so I thought I'd just get it replaced instead of having to deal with it.

[Hi-Angel]

Do bridgman have an info to share with the forum for whether there is a CPU microcode update that fixes the problem?

[Hi-Angel]

Ryzen 5 1600 is not affected when manufactured after week 20 or so. Mine is from week 33. Cpu uses 2666Mhz ddr4 so buy that. Many motherboards drops memory speed to 2100Mhz with 3000Mhz + modules, see the motherboard docs.

Well, I guess it's impossible to know before buying the CPU.

Also AGESA 1.0.0.6B Bios update fixes early Ryzen problem.

Hmm, I see above someone experiencing problems with the bios update.

Either way, if it's fixed by BIOS update, then it's probably fixed in CPU microcode update carried with the BIOS. But why is AMD replacing the CPUs then? Distros do have packages with CPU microcode, there's no need to even update the BIOS. Somethings not right…

[haagch]

My 1600X with the ram at default 2133mhz or so crashed gcc regularly. I've asked my local shop whether they replace it there, but no, you have to send it to AMD. According to the tracking they've had it for 6 days now. It's a long time without a CPU...

[schmidtbag]

My friend builds up a PC. She is developer too, so compiling something is to be expected. She wanted RYZEN 5 1600 — as I understand it's affected? Anyway, is there a specific way to buy Ryzen that is not affected by the problem? Or is buying and replacing — the only way?

If you are to buy a new Ryzen 1600, there's a pretty good chance it will be perfectly fine. I think in most cases you can compile large projects without any issue, especially if you keep the RAM below 3200MHz and don't OC the CPU too much. I have a 1500X from one of the early batches and depending on my clock settings it can take from 10 minutes to over an hour with this glitch. So even in a worst-case scenario, it's hardly a threat.

[Hi-Angel]

My friend builds up a PC. She is developer too, so compiling something is to be expected. She wanted RYZEN 5 1600 — as I understand it's affected? Anyway, is there a specific way to buy Ryzen that is not affected by the problem? Or is buying and replacing — the only way?

[keantoken]

timon37

I had a UA1715SUS that gave segfaults and random reboots. AMD replaced it with a UA1728SUS which doesn't give segfaults, reboots TBD. It also fixed keyboard and mouse input errors (evbug). It is a Ryzen 5 1500X.

Curiously, my system log was filling up with evbug: errors from the keyboard and mouse. That's not happening anymore. I actually had to change my mouse because my Kensington mouse-in-a-box caused both the keyboard and mouse to lock up and not accept input.

[cusa123]

"agesa 1.0.0.6" bios f6

[KERN] -- Logs begin at Sat 2017-09-16 23:06:35 UYT. --
[KERN] Sep 16 23:06:43 amdryzen-AX370-Gaming-5 kernel: nvidia-modeset: WARNING: GPU:0: Unable to read EDID for display device DVI-I-0
[KERN] Sep 16 23:06:45 amdryzen-AX370-Gaming-5 kernel: nvidia-modeset: WARNING: GPU:0: Unable to read EDID for display device DVI-I-0
[KERN] Sep 16 23:06:45 amdryzen-AX370-Gaming-5 kernel: nvidia-modeset: WARNING: GPU:0: Unable to read EDID for display device DVI-I-0
[KERN] Sep 16 23:06:45 amdryzen-AX370-Gaming-5 kernel: nvidia-modeset: WARNING: GPU:0: Unable to read EDID for display device DVI-I-0
[KERN] Sep 16 23:06:45 amdryzen-AX370-Gaming-5 kernel: nvidia-modeset: WARNING: GPU:0: Unable to read EDID for display device DVI-I-0
[KERN] Sep 16 23:06:45 amdryzen-AX370-Gaming-5 kernel: nvidia-modeset: WARNING: GPU:0: Unable to read EDID for display device DVI-I-0
[KERN] Sep 16 23:06:46 amdryzen-AX370-Gaming-5 kernel: nvidia-modeset: WARNING: GPU:0: Unable to read EDID for display device DVI-I-0
[KERN] Sep 16 23:07:37 amdryzen-AX370-Gaming-5 kernel: zram: Added device: zram0
[KERN] Sep 16 23:07:37 amdryzen-AX370-Gaming-5 kernel: zram0: detected capacity change from 0 to 68719476736
[KERN] Sep 16 23:07:37 amdryzen-AX370-Gaming-5 kernel: EXT4-fs (zram0): mounted filesystem with ordered data mode. Opts: discard
_________________________________________________

[loop-10] Sat Sep 16 23:11:16 UYT 2017 build failed
[loop-10] TIME TO FAIL: 132 s
[KERN] Sep 16 23:11:16 amdryzen-AX370-Gaming-5 kernel: bash[23348]: segfault at 91afc8 ip 000000000091afc8 sp 00007fff241e2460 error 15

_________________________________________________

_________________________________________________

Agesa 1.0.0.6b -> bios f9 -> test 1

[loop-9] TIME TO FAIL: 118 s
[loop-0] TIME TO FAIL: 118 s
[KERN] Sep 17 11:28:56 amdryzen-AX370-Gaming-5 kernel: bash[29611]: segfault at 64 ip 00000000004b88f0 sp 00007ffe1250ccb8 error 4 in bash[400000+f4000]
[KERN] Sep 17 11:28:56 amdryzen-AX370-Gaming-5 kernel: bash[29506]: segfault at 64 ip 00000000004b88f0 sp 00007ffddc8ec938 error 4 in bash[400000+f4000]
___________

test 2 -> emulation 60/64

[loop-9] Sun Sep 17 11:46:24 UYT 2017 build failed
[loop-9] TIME TO FAIL: 118 s
[KERN] Sep 17 11:46:24 amdryzen-AX370-Gaming-5 kernel: traps: bash[27753] trap invalid opcode ip:48db90 sp:7ffc66b917c8 error:0 in bash[400000+f4000]
-------------------- Test 3-> opcache control "disabled" It works better!

[loop-13] Sun Sep 17 12:44:14 UYT 2017 start 0
[loop-14] Sun Sep 17 12:44:15 UYT 2017 start 0
[loop-15] Sun Sep 17 12:44:16 UYT 2017 start 0
[KERN] Sep 17 13:14:36 amdryzen-AX370-Gaming-5 kernel: perf: interrupt took too long (2501 > 2500), lowering kernel.perf_event_max_sample_rate to 79750

I don't understand the mistake at the end.
Ryzen 1700 , ax370 gigabyte gaming 5 , 16 gb ram 2400mhz, gtx 970 sc nvidia, 1 ssd kingstone v300 + hdd 500gb. Linux mint 18.2 , gcc 7.1.0,kernel 4.13.2-041302-generi

[audir8]

phoronix-test-suite run build-gcc might be having failed test runs because of this. I had 1-2 successful runs, then a failed one, then another successful one. Turning the opcode cache off gets rid of the problem or makes it disappear for hours. The performance penalty seems to be negligible in pts/build-kernel runs for me. The problem does still happen at higher Vcore at 1.25 and for RAM speeds from 2133-2800 with opcode cache on. I can't guarantee a good RMA with Newegg, so dealing with AMD customer care now. Hopefully this is a Global Foundry and/or AMD hiccup and really fixed in newer versions. Seems like the opcode cache wouldn't be shared between cores or chips...

edit: Disabling the opcode cache would be a "performance maginality" in the grand scheme of things. That being said, AMD should have recognized the problem earlier and been more proactive in actually fixing the problem by replacing the processors or giving some sort of a discount.