freebsd stable - Jan 2018 - Ryzen issues on FreeBSD ? (summary of 4 issues)

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 at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe at
freebsd.org"
> 
> 

-- 
-------------------
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, mike at sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/

I'm not sure this is characterized quite right.  I've been seeing c)
where
the system freezes completely and seems to be related to idle/ low load,
but the workaround that seems to be working around the issue is part of a)
where I lowered the memory speed.


On Wed, Jan 24, 2018 at 9:42 AM Mike Tancsa <mike at sentex.net> wrote:
> 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
>
> --
--
Nimrod

On 24 January 2018 at 15:42, Mike Tancsa <mike at sentex.net>
wrote:
> 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)
According to post #39 in the referenced Linux thread
(https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1690085): "It
was officially fixed for all ryzen manufactured after week 30."

I currently have a Ryzen 1600X from week 17/30, which suggests it will
have the bug. Unfortunately, I don't have it built into a system yet
as I'm waiting for DDR4 prices to become reasonable again before
ordering any, so I can't test it.

I'm not sure how solid this info is, should I RMA it without even
having tested that it has a problem?

Alban Hertroys
-- 
If you can't see the forest for the trees,
Cut the trees and you'll see there is no forest.