Date: Wed, 24 Jan 2018 09:42:50 -0500 From: Mike Tancsa <mike@sentex.net> To: Mark Millard <marklmi26-fbsd@yahoo.com>, nimrodl@gmail.com, michaelp@bsquare.com, FreeBSD-STABLE Mailing List <freebsd-stable@freebsd.org> Subject: Re: Ryzen issues on FreeBSD ? (summary of 4 issues) Message-ID: <744bbe18-80c4-d057-c88d-fbe480ee9abb@sentex.net> In-Reply-To: <A6A50EB1-6944-40B4-9F33-002336F582E6@yahoo.com> References: <A6A50EB1-6944-40B4-9F33-002336F582E6@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I think perhaps a good time to summarize as a few issues seem to be going on a) fragile BIOS settings. There seems to be a number of issues around RAM speeds and disabled C-STATES that impact stability. Specifically, lowering the default frequency from 2400 to 2133 seems to help some users with crashes / lockups under heavy loads. b) CPUs manufactured prior to week 25 (some say week 33?) have a hardware defect that manifests itself as segfaults in heavy compiles. I was able to confirm this on 1 of the CPUs I had using a Linux setup. It seems to confirm this, you need to physically look at the CPU for the manufacturing date :( Not sure how to trigger it on FreeBSD reliably, but there is a github project I used to verify on Linux (https://github.com/suaefar/ryzen-test) c) The idle lockup bug. This *seems* to be confirmed on Linux as well http://blog.programster.org/ubuntu-16-04-compile-custom-kernel-for-ryzen and https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1690085 d) Compile failures of some ports. For myself and one other user, compiling net/samba47 reliably hangs in roughly the same place. Its not clear if this is related to any of the above bugs or not. Right now I have RMA'd my 3 CPUs back to AMD. Hopefully, I will get replacements in a week and can get back to testing c) and d). ---Mike On 1/24/2018 9:22 AM, Mark Millard via freebsd-stable wrote: > Mike Pumford michaelp at bsquare.com wrote on > Wed Jan 24 12:03:04 UTC 2018 : > >> I've run into this on modern Intel systems as well. The RAM is sold as >> 2400 but thats actually an overclock profile. If I actually enabled it >> (despite both board and RAM being qualified for that) the system ends up >> locking up or crashing as soon as you stress it. Go back to the standard >> DDR profile advertised by the RAM and it is totally stable. > > The reported fails are during idle time as I understand. Things are > working when the CPU's are kept busy from what I've read in the > various notes. The hang-ups are during idle times. > > "the system ends up locking up or crashing as soon as you stress it" > does not sound like a matching context. > > That a slower RAM speed might help idle behave correctly is interesting > given the Zen and Ryzen dependence on RAM speed for the speed of its > internal interconnect-fabric's operation. > > I'll note that, if one goes through the referenced Linux exchanges about > this, Ryzen Threadripper's examples are also reported to have the problem. > > === > Mark Millard > marklmi at yahoo.com > ( markmi at dsl-only.net is > going away in 2018-Feb, late) > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?744bbe18-80c4-d057-c88d-fbe480ee9abb>