drescherjm
[H]F Junkie
- Joined
- Nov 19, 2008
- Messages
- 14,941
Really this is AMD's fault. Some time ago they reset the AGESA numbers and started over.
1.0.0.4 is newer than the old 1.0.0.6b from last year.
https://community.amd.com/thread/231489
Follow along with the video below to see how to install our site as a web app on your home screen.
Note: This feature may not be available in some browsers.
Really this is AMD's fault. Some time ago they reset the AGESA numbers and started over.
1.0.0.4 is newer than the old 1.0.0.6b from last year.
Really this is AMD's fault. Some time ago they reset the AGESA numbers and started over.
1.0.0.4 is newer than the old 1.0.0.6b from last year.
I can understand your frustration with this. I am glad I waited to purchase Ryzen2 instead of Ryzen1 for my linux server / pvr.
When were these claims regarding the normal desktop variants? I do remember reading something about the segfault problem but I also thought I read reports that it has been fixed since. So, when were these claims posted and have you heard/read anything about a fix?Ryzen 2 suffers from the exact same issues as Ryzen 1. People have had the segfault bug on the 2x00G APUs and the normal desktop variants as well.
When were these claims regarding the normal desktop variants? I do remember reading something about the segfault problem but I also thought I read reports that it has been fixed since. So, when were these claims posted and have you heard/read anything about a fix?
Do you have any sources that the bug is still present with Ryzen 2 processors?There are kernel bug reports about Ryzen processors of all models and all configurations up until today. There is no single setting that will fix them either, there are dozens of different methods involving playing musical chairs with hardware, dicking around with UEFI settings, various kernel boot parameters, compiling custom kernels with various options, etc.
You'd figure that millions of people plugging away at this problem for more than a year would be able to solve it, but that's not the case.
Do you have any sources that the bug is still present with Ryzen 2 processors?
The workarounds mentioned there should avoid the problem entirely.
Note that for rcu_nocbs=... to work in particular, your kernel needs CONFIG_RCU_NOCB_CPU enabled.
This, perhaps?:3 months ago with ongoing discussion. I can't find the bugzilla log I was reading before, but it had 450+ entries of people complaining about hard locks with all Ryzen CPUs, regardless of whether 1000 or 2000 series.
Buy Intel, Sell AMD.
If deep pockets, buy a Talos II POWER9 workstation and abandon the sinking x86 ship early. Both blue and red have severe problems with unfixable CPU bugs that date back to the mid 90s (meltdown, spectre, etc.)
At least with the POWER9, you can go all the way down to the CPU firmware to make sure there are no hidden intel management engines, cyrix control chips or AMD "TrustZone"
This, perhaps?:
https://bugzilla.kernel.org/show_bug.cgi?id=196683
If it's happening to you, I would make sure the mobo is using the most current BIOS (you are using an Asus mobo, maybe?) and go to the BIOS settings and check to see a setting is at 'Typical Current Idle.' You only have to read the last few/bunch of comments - I would try that and see if it makes a difference.
Okay, sorry. I don't mean to annoy you - if you have tried it already and are familiar with the links I posted. That really sucks. I use Linux primarily, so I think it is worrisome to consider an AMD (Ryzen) system - I know I would be annoyed with frequent freezes or crashes stemming from some BIOS/power or cpu-related issue - the more frustrating part of it seems to be no real explanation or sign of an upcoming solution. I think on the amd reddit, some AMD employees sometimes visit so someone should post about this?Already tried all of the "fixes" outlined in the thread and elsewhere. I've spent weeks doing this.
Both boards have had their BIOSes flashed to different versions, UEFI settings changed, etc.
Okay, sorry. I don't mean to annoy you - if you have tried it already and are familiar with the links I posted.
I'm not sure what to go with but perhaps, I should re-consider the Intel build - the Spectre/Meltdown thing sucks but the latest reports indicate it's a small penalty and the fixes seem to be okay. It hasn't stopped people from still buying Intel hardware - I am only buying the mobo new so not really supporting them (either) that much.
I hear ya.... also, I read the other replies to you on this and I read the replies in those threads of people telling you to modify kernel lines/code etc. etc. and I think that's outrageous. Even one person said 'you shouldn't have to do this' and I agree with him. I think it was in the bugzilla thread.I think you'd be annoyed too if you spent hundreds of dollars on hardware that was broken and manufacturers offer no definitive fix for it being broken, AND you can't return or sell it because it's defective. I keep a fairly hefty pile of spare hardware around, so I could swap everything multiple times (except the board and CPU), but it was still an aggravating process of the machine taking up room and being a constant state of discombobulation.
The meltdown software fixes only minimally impact the latest hardware, you have to understand that every Intel CPU since the Pentium is affected by it, and the older you go, the more of a performance impact it will have. Though, beyond a certain point, software patches are unavailable. Microsoft isn't going to blow the dust off the Windows 98 source code and implement a fix for it. For others it's slightly more problematic, there are still plenty of late Core 2 CPUs and machines floating around running Windows 7/8/10 and those machines are going to be the most heavily impacted with perf hits.
I would recommend Intel, but not their latest gen parts because Linux support is spotty. The 6th gen is the latest I'd go right now, which is what I use for my main gaming rig.
However, I think I read that this issue doesn't occur in Windows which is peculiar, isn't it?
I know that they admitted to some other (different?; same?) problem and were willing to exchange processors. However, that didn't seem to solve the problem for a lot of customers. Maybe, it's a defect or flaw in the component that can't easily be fixed or something? Or perhaps, only some lucky owners can 'find' a fix? Dunno.
P.S. I have an Intel Core 2 Quad cpu. Q6600. I believe I'm effected. :-(
[root@Phobos-IV]# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 23
model name : Pentium(R) Dual-Core CPU E6300 @ 2.80GHz
stepping : 10
microcode : 0xa0b
cpu MHz : 1600.024
cache size : 2048 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl cpuid aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm xsave lahf_lm pti tpr_shadow vnmi flexpriority dtherm
bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass
bogomips : 5599.98
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
I'm posting this on the possible chance you haven't tried this one setting change yet...
Link:
""Deep Sleep State" - 'not familiar with it but apparently it's disabled in the BIOS - and the author is saying to enable that setting. If you are still having issues (obviously - you are?) and you haven't tried that change then I suggest you have nothing to lose trying it? Then, enable the other settings, C6 etc. - don't use kernel parameter edits etc.
What distro and what kernel? Maybe something bleeding edge like openSUSE Tumbleweed which has a very current kernel version, that's what I use on my rma'd 1500X + Asus Prime B350.
ASRock calls the setting that fixes this "global C-state control" (actually affecting DF / uncore apparently). I would be uncomfortable disabling that with 2800+ RAM, because that bumps VSoC way up on OG Zen, but with 2666 that shouldn't be a problem and it has surprisingly little effect on power consumption.
(I had the same problem with an R7 1700 and that's been a solid fix.)
What happened when you tried enabling that setting? Btw, Fedora 28? What kernel are you using? I think you should be using, at least, kernel 4.18.8 or later - so might need to upgrade the kernel if you're not at that version or later. Most of the people claiming their system was working seemed to be using a really recent kernel and I think the stable one is 4.18 but people were still saying they were having lockups. I haven't read of anyone using 4.18.8 or later claiming any.Currently, Fedora 28 with latest updates. But I have tried Xubuntu 18.04 and OpenSUSE 42.3. I'm reluctant to change the OS again since I've spent the last day migrating files, scripts and configs over to it from by backup server and don't really want to have to do it again. Might do more experiments when the Gigabyte board comes back from RMA.
Fedora 28 on the Asus Prime B450M-A and the RMA'd CPU has only frozen once on a screen saver, it hasn't done it again yet. I'm going out of town the next 4 days so I'll see if it's locked up when I return.
I believe I remember seeing that option and I think that I turned it on, but not 100% sure. I'll have to look at it when I get back in 4 days.
I haven't run the RAM at its rated speed but once on the old motherboard and it was so unstable that I just opted to leave it at 2133. Currently the Patriot RAM isn't even in the machine because I think it's part of the problem. It's currently running on a single 4 GB stick of generic Altex RAM.
What happened when you tried enabling that setting? Btw, Fedora 28? What kernel are you using? I think you should be using, at least, kernel 4.18.8 or later - so might need to upgrade the kernel if you're not at that version or later. Most of the people claiming their system was working seemed to be using a really recent kernel and I think the stable one is 4.18 but people were still saying they were having lockups. I haven't read of anyone using 4.18.8 or later claiming any.
Did you read that post by that Reddit user? He claimed that the default was that it is disabled. The other settings are enabled. The only way you can both be right is if the mobo manufacturers were changing their BIOS defaults?It's something that's enabled by default, and the fix is disabling it, not the other way around. IIRC the options are auto/enabled/disabled though, so that may not be completely clear just looking at it.
They use different menu names and hide different settings, different defaults would not surprise me. That said, doesn't hurt to try both.Did you read that post by that Reddit user? He claimed that the default was that it is disabled. The other settings are enabled. The only way you can both be right is if the mobo manufacturers were changing their BIOS defaults?
Don't toss it! Most ram is lifetime warranted, you could sell it as is, or RMA it and sell what you get back.
ASRock calls the setting that fixes this "global C-state control" (actually affecting DF / uncore apparently). I would be uncomfortable disabling that with 2800+ RAM, because that bumps VSoC way up on OG Zen, but with 2666 that shouldn't be a problem and it has surprisingly little effect on power consumption.
(I had the same problem with an R7 1700 and that's been a solid fix.)
What happened when you tried enabling that setting? Btw, Fedora 28? What kernel are you using? I think you should be using, at least, kernel 4.18.8 or later - so might need to upgrade the kernel if you're not at that version or later. Most of the people claiming their system was working seemed to be using a really recent kernel and I think the stable one is 4.18 but people were still saying they were having lockups. I haven't read of anyone using 4.18.8 or later claiming any.
May not help you at all, and I skimmed through the whole thread but may have missed it. Still, I've had issues with it on more than one occasion, and I tend to forget it often, so it doesn't hurt to try:
I see you updated BIOSes. Did you try resetting settings using the Clear CMOS jumper on the MoBo?