Re: Ryzen issues on FreeBSD ?

2018-01-27 Thread Peter Moody 
On Jan 27, 2018 6:20 PM, "Nimrod Levy"  wrote:

I'm about ready to have a party.  My Ryzen 5 1600 has been up for over 8
days so far after changing the memory to a slower speed.  System load
hovers around .3


I couldn't find an easy way to down-speed my memory in the bios :(



On Sat, Jan 27, 2018 at 8:41 PM Peter Moody  wrote:

> Whelp, I replaced the r5 1600x with an r7 1700 (au 1734) and I'm now
> getting minutes of uptime before I hard crash. With smt, without, with c
> states, without, with opcache, without. No difference.
>
> I'm going to try a completely different motherboard next. I think Amazon
> is starting to dislike me.
>
> On Jan 21, 2018 11:05 AM, "Peter Moody"  wrote:
>
>> hm, so i've got nearly 3 days of uptime with smt disabled.
>> unfortunately this means that my otherwise '12' cores is actually only
>> '6'. I'm also getting occasional segfaults compiling go programs.
>>
>> should I just RMA this beast again?
>>
>> On Sun, Jan 21, 2018 at 5:25 AM, Nimrod Levy  wrote:
>> > almost 2 days uptime with a lower memory clock. still holding my breath,
>> > but this seems promising.
>> >
>> >
>> >
>> > On Fri, Jan 19, 2018 at 4:02 PM Nimrod Levy  wrote:
>> >
>> >> I can try lowering my memory clock and see what happens.  I'm a little
>> >> skeptical because I have been able to run memtest with no errors for
>> some
>> >> time.  I'm glad to give anything a try...
>> >>
>> >>
>> >> On Fri, Jan 19, 2018 at 3:49 PM Mike Tancsa  wrote:
>> >>
>> >>> On 1/19/2018 3:23 PM, Ryan Root wrote:
>> >>> > This looks like the QVL list for your MB ->
>> >>> >
>> >>> http://download.gigabyte.us/FileList/Memory/mb_memory_ga-
>> ax370-Gaming5.pdf
>> >>>
>> >>> Its an Asus MB, but the memory I have is in the above PDF list
>> >>>
>> >>> I dont see CT16G4DFD824A, but I do see other crucial products with
>> >>> slower clock speeds. Right now I do have it set to 2133 where as it
>> was
>> >>> 2400 before.
>> >>>
>> >>> ---Mike
>> >>>
>> >>>
>> >>> >
>> >>> >
>> >>> > On 1/19/2018 12:13 PM, Mike Tancsa wrote:
>> >>> >> Drag :( I have mine disabled as well as lowering the RAM freq to
>> 2100
>> >>> >> from 2400.  For me the hangs are infrequent.  Its only been a day
>> and a
>> >>> >> half, so not sure if its gone or I have been "lucky"... Either
>> ways,
>> >>> >> this platform feels way too fragile to deploy on anything :(
>> >>> >>
>> >>> >>  ---Mike
>> >>> >>
>> >>> >> On 1/19/2018 3:08 PM, Nimrod Levy wrote:
>> >>> >>> Looks like disabling the C- states in the bios didn't change
>> >>> anything.
>> >>> >>>
>> >>> >>> On Wed, Jan 17, 2018 at 9:22 PM Nimrod Levy > >>> >>> > wrote:
>> >>> >>>
>> >>> >>> That looks promising. I just found that seeing in the bios and
>> >>> >>> disabled it. I'll see how it runs.
>> >>> >>>
>> >>> >>> Thanks
>> >>> >>>
>> >>> >>>
>> >>> >>> On Wed, Jan 17, 2018, 18:38 Don Lewis > >>> >>> > wrote:
>> >>> >>>
>> >>> >>> On 17 Jan, Nimrod Levy wrote:
>> >>> >>> > I'm running 11-STABLE from 12/9.  amdtemp works for
>> me.  It
>> >>> >>> also has the
>> >>> >>> > systl indicating that it it has the shared page fix. I'm
>> >>> >>> pretty sure I've
>> >>> >>> > seen the lockups since then.  I'll update to the latest
>> >>> STABLE
>> >>> >>> and see
>> >>> >>> > what  happens.
>> >>> >>> >
>> >>> >>> > One weird thing about my experience is that if I keep
>> >>> >>> something running
>> >>> >>> > continuously like the distributed.net <
>> >>> http://distributed.net>
>> >>> >>> client on 6 of 12 possible threads,
>> >>> >>> > it keeps the system up for MUCH longer than without.
>> This
>> >>> is
>> >>> >>> a home server
>> >>> >>> > and very lightly loaded (one could argue insanely
>> >>> overpowered
>> >>> >>> for the use
>> >>> >>> > case).
>> >>> >>>
>> >>> >>> This sounds like the problem with the deep Cx states that
>> has
>> >>> been
>> >>> >>> reported by numerous Linux users.  I think some
>> motherboard
>> >>> >>> brands are
>> >>> >>> more likely to have the problem.  See:
>> >>> >>>
>> >>> http://forum.asrock.com/forum_posts.asp?TID=5963=
>> taichi-x370-with-ubuntu-idle-lock-ups-idle-freeze
>> >>> >>>
>> >>> >>> --
>> >>> >>>
>> >>> >>> --
>> >>> >>> Nimrod
>> >>> >>>
>> >>> >>>
>> >>> >>>
>> >>> >>> --
>> >>> >>>
>> >>> >>> --
>> >>> >>> Nimrod
>> >>> >>>
>> >>> >>
>> >>> >
>> >>> >
>> >>> > ___
>> >>> > freebsd-stable@freebsd.org mailing list
>> >>> > https://lists.freebsd.org/mailman/listinfo/freebsd-stable
>> >>> > To unsubscribe, send any mail to "
>> >>> freebsd-stable-unsubscr...@freebsd.org"
>> >>> >
>> >>> >
>>

Re: Ryzen issues on FreeBSD ?

2018-01-27 Thread Nimrod Levy 
I'm about ready to have a party.  My Ryzen 5 1600 has been up for over 8
days so far after changing the memory to a slower speed.  System load
hovers around .3


On Sat, Jan 27, 2018 at 8:41 PM Peter Moody  wrote:

> Whelp, I replaced the r5 1600x with an r7 1700 (au 1734) and I'm now
> getting minutes of uptime before I hard crash. With smt, without, with c
> states, without, with opcache, without. No difference.
>
> I'm going to try a completely different motherboard next. I think Amazon
> is starting to dislike me.
>
> On Jan 21, 2018 11:05 AM, "Peter Moody"  wrote:
>
>> hm, so i've got nearly 3 days of uptime with smt disabled.
>> unfortunately this means that my otherwise '12' cores is actually only
>> '6'. I'm also getting occasional segfaults compiling go programs.
>>
>> should I just RMA this beast again?
>>
>> On Sun, Jan 21, 2018 at 5:25 AM, Nimrod Levy  wrote:
>> > almost 2 days uptime with a lower memory clock. still holding my breath,
>> > but this seems promising.
>> >
>> >
>> >
>> > On Fri, Jan 19, 2018 at 4:02 PM Nimrod Levy  wrote:
>> >
>> >> I can try lowering my memory clock and see what happens.  I'm a little
>> >> skeptical because I have been able to run memtest with no errors for
>> some
>> >> time.  I'm glad to give anything a try...
>> >>
>> >>
>> >> On Fri, Jan 19, 2018 at 3:49 PM Mike Tancsa  wrote:
>> >>
>> >>> On 1/19/2018 3:23 PM, Ryan Root wrote:
>> >>> > This looks like the QVL list for your MB ->
>> >>> >
>> >>>
>> http://download.gigabyte.us/FileList/Memory/mb_memory_ga-ax370-Gaming5.pdf
>> >>>
>> >>> Its an Asus MB, but the memory I have is in the above PDF list
>> >>>
>> >>> I dont see CT16G4DFD824A, but I do see other crucial products with
>> >>> slower clock speeds. Right now I do have it set to 2133 where as it
>> was
>> >>> 2400 before.
>> >>>
>> >>> ---Mike
>> >>>
>> >>>
>> >>> >
>> >>> >
>> >>> > On 1/19/2018 12:13 PM, Mike Tancsa wrote:
>> >>> >> Drag :( I have mine disabled as well as lowering the RAM freq to
>> 2100
>> >>> >> from 2400.  For me the hangs are infrequent.  Its only been a day
>> and a
>> >>> >> half, so not sure if its gone or I have been "lucky"... Either
>> ways,
>> >>> >> this platform feels way too fragile to deploy on anything :(
>> >>> >>
>> >>> >>  ---Mike
>> >>> >>
>> >>> >> On 1/19/2018 3:08 PM, Nimrod Levy wrote:
>> >>> >>> Looks like disabling the C- states in the bios didn't change
>> >>> anything.
>> >>> >>>
>> >>> >>> On Wed, Jan 17, 2018 at 9:22 PM Nimrod Levy > >>> >>> > wrote:
>> >>> >>>
>> >>> >>> That looks promising. I just found that seeing in the bios and
>> >>> >>> disabled it. I'll see how it runs.
>> >>> >>>
>> >>> >>> Thanks
>> >>> >>>
>> >>> >>>
>> >>> >>> On Wed, Jan 17, 2018, 18:38 Don Lewis > >>> >>> > wrote:
>> >>> >>>
>> >>> >>> On 17 Jan, Nimrod Levy wrote:
>> >>> >>> > I'm running 11-STABLE from 12/9.  amdtemp works for
>> me.  It
>> >>> >>> also has the
>> >>> >>> > systl indicating that it it has the shared page fix. I'm
>> >>> >>> pretty sure I've
>> >>> >>> > seen the lockups since then.  I'll update to the latest
>> >>> STABLE
>> >>> >>> and see
>> >>> >>> > what  happens.
>> >>> >>> >
>> >>> >>> > One weird thing about my experience is that if I keep
>> >>> >>> something running
>> >>> >>> > continuously like the distributed.net <
>> >>> http://distributed.net>
>> >>> >>> client on 6 of 12 possible threads,
>> >>> >>> > it keeps the system up for MUCH longer than without.
>> This
>> >>> is
>> >>> >>> a home server
>> >>> >>> > and very lightly loaded (one could argue insanely
>> >>> overpowered
>> >>> >>> for the use
>> >>> >>> > case).
>> >>> >>>
>> >>> >>> This sounds like the problem with the deep Cx states that
>> has
>> >>> been
>> >>> >>> reported by numerous Linux users.  I think some
>> motherboard
>> >>> >>> brands are
>> >>> >>> more likely to have the problem.  See:
>> >>> >>>
>> >>>
>> http://forum.asrock.com/forum_posts.asp?TID=5963=taichi-x370-with-ubuntu-idle-lock-ups-idle-freeze
>> >>> >>>
>> >>> >>> --
>> >>> >>>
>> >>> >>> --
>> >>> >>> Nimrod
>> >>> >>>
>> >>> >>>
>> >>> >>>
>> >>> >>> --
>> >>> >>>
>> >>> >>> --
>> >>> >>> Nimrod
>> >>> >>>
>> >>> >>
>> >>> >
>> >>> >
>> >>> > ___
>> >>> > freebsd-stable@freebsd.org mailing list
>> >>> > https://lists.freebsd.org/mailman/listinfo/freebsd-stable
>> >>> > To unsubscribe, send any mail to "
>> >>> freebsd-stable-unsubscr...@freebsd.org"
>> >>> >
>> >>> >
>> >>>
>> >>>
>> >>> --
>> >>> ---
>> >>> Mike Tancsa, tel +1 519 651 3400 <(519)%20651-3400>
>> >>> Sentex Communications,

Re: Ryzen issues on FreeBSD ?

2018-01-27 Thread Peter Moody 
Whelp, I replaced the r5 1600x with an r7 1700 (au 1734) and I'm now
getting minutes of uptime before I hard crash. With smt, without, with c
states, without, with opcache, without. No difference.

I'm going to try a completely different motherboard next. I think Amazon is
starting to dislike me.

On Jan 21, 2018 11:05 AM, "Peter Moody"  wrote:

> hm, so i've got nearly 3 days of uptime with smt disabled.
> unfortunately this means that my otherwise '12' cores is actually only
> '6'. I'm also getting occasional segfaults compiling go programs.
>
> should I just RMA this beast again?
>
> On Sun, Jan 21, 2018 at 5:25 AM, Nimrod Levy  wrote:
> > almost 2 days uptime with a lower memory clock. still holding my breath,
> > but this seems promising.
> >
> >
> >
> > On Fri, Jan 19, 2018 at 4:02 PM Nimrod Levy  wrote:
> >
> >> I can try lowering my memory clock and see what happens.  I'm a little
> >> skeptical because I have been able to run memtest with no errors for
> some
> >> time.  I'm glad to give anything a try...
> >>
> >>
> >> On Fri, Jan 19, 2018 at 3:49 PM Mike Tancsa  wrote:
> >>
> >>> On 1/19/2018 3:23 PM, Ryan Root wrote:
> >>> > This looks like the QVL list for your MB ->
> >>> >
> >>> http://download.gigabyte.us/FileList/Memory/mb_memory_ga-
> ax370-Gaming5.pdf
> >>>
> >>> Its an Asus MB, but the memory I have is in the above PDF list
> >>>
> >>> I dont see CT16G4DFD824A, but I do see other crucial products with
> >>> slower clock speeds. Right now I do have it set to 2133 where as it was
> >>> 2400 before.
> >>>
> >>> ---Mike
> >>>
> >>>
> >>> >
> >>> >
> >>> > On 1/19/2018 12:13 PM, Mike Tancsa wrote:
> >>> >> Drag :( I have mine disabled as well as lowering the RAM freq to
> 2100
> >>> >> from 2400.  For me the hangs are infrequent.  Its only been a day
> and a
> >>> >> half, so not sure if its gone or I have been "lucky"... Either ways,
> >>> >> this platform feels way too fragile to deploy on anything :(
> >>> >>
> >>> >>  ---Mike
> >>> >>
> >>> >> On 1/19/2018 3:08 PM, Nimrod Levy wrote:
> >>> >>> Looks like disabling the C- states in the bios didn't change
> >>> anything.
> >>> >>>
> >>> >>> On Wed, Jan 17, 2018 at 9:22 PM Nimrod Levy  >>> >>> > wrote:
> >>> >>>
> >>> >>> That looks promising. I just found that seeing in the bios and
> >>> >>> disabled it. I'll see how it runs.
> >>> >>>
> >>> >>> Thanks
> >>> >>>
> >>> >>>
> >>> >>> On Wed, Jan 17, 2018, 18:38 Don Lewis  >>> >>> > wrote:
> >>> >>>
> >>> >>> On 17 Jan, Nimrod Levy wrote:
> >>> >>> > I'm running 11-STABLE from 12/9.  amdtemp works for me.
> It
> >>> >>> also has the
> >>> >>> > systl indicating that it it has the shared page fix. I'm
> >>> >>> pretty sure I've
> >>> >>> > seen the lockups since then.  I'll update to the latest
> >>> STABLE
> >>> >>> and see
> >>> >>> > what  happens.
> >>> >>> >
> >>> >>> > One weird thing about my experience is that if I keep
> >>> >>> something running
> >>> >>> > continuously like the distributed.net <
> >>> http://distributed.net>
> >>> >>> client on 6 of 12 possible threads,
> >>> >>> > it keeps the system up for MUCH longer than without.
> This
> >>> is
> >>> >>> a home server
> >>> >>> > and very lightly loaded (one could argue insanely
> >>> overpowered
> >>> >>> for the use
> >>> >>> > case).
> >>> >>>
> >>> >>> This sounds like the problem with the deep Cx states that
> has
> >>> been
> >>> >>> reported by numerous Linux users.  I think some motherboard
> >>> >>> brands are
> >>> >>> more likely to have the problem.  See:
> >>> >>>
> >>> http://forum.asrock.com/forum_posts.asp?TID=5963=
> taichi-x370-with-ubuntu-idle-lock-ups-idle-freeze
> >>> >>>
> >>> >>> --
> >>> >>>
> >>> >>> --
> >>> >>> Nimrod
> >>> >>>
> >>> >>>
> >>> >>>
> >>> >>> --
> >>> >>>
> >>> >>> --
> >>> >>> Nimrod
> >>> >>>
> >>> >>
> >>> >
> >>> >
> >>> > ___
> >>> > freebsd-stable@freebsd.org mailing list
> >>> > https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> >>> > To unsubscribe, send any mail to "
> >>> freebsd-stable-unsubscr...@freebsd.org"
> >>> >
> >>> >
> >>>
> >>>
> >>> --
> >>> ---
> >>> Mike Tancsa, tel +1 519 651 3400 <(519)%20651-3400>
> >>> Sentex Communications, m...@sentex.net
> >>> Providing Internet services since 1994 www.sentex.net
> >>> Cambridge, Ontario Canada   http://www.tancsa.com/
> >>> ___
> >>> 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"
> >>>
>

Re: Ryzen issues on FreeBSD ?

2018-01-27 Thread Mark Millard via freebsd-stable 
Don Lewis truckman at FreeBSD.org wrote on
Sat Jan 27 08:23:27 UTC 2018 :

>   PIDTID COMMTDNAME  CPU  PRI STATE   WCHAN   
>  
> 90692 100801 python2.7   --1  124 sleep   usem
>   
> 90692 100824 python2.7   --1  124 sleep   usem
>   
. . .


# grep -r '"usem"' /usr/src/sys/
/usr/src/sys/dev/qlnx/qlnxe/ecore_dbg_fw_funcs.c:   "usem", { true, true, 
true }, true, DBG_USTORM_ID,
/usr/src/sys/kern/kern_umtx.c:  error = umtxq_sleep(uq, "usem", timeout == NULL 
? NULL : );
/usr/src/sys/kern/kern_umtx.c:  error = umtxq_sleep(uq, "usem", timeout == NULL 
? NULL : );

/usr/src/sys/kern/kern_umtx.c has :

#if defined(COMPAT_FREEBSD9) || defined(COMPAT_FREEBSD10)
static int
do_sem_wait(struct thread *td, struct _usem *sem, struct _umtx_time *timeout)
{
. . .
error = umtxq_sleep(uq, "usem", timeout == NULL ? NULL : );
. . .
#endif
. . .
static int
do_sem2_wait(struct thread *td, struct _usem2 *sem, struct _umtx_time *timeout)
{
. . .
error = umtxq_sleep(uq, "usem", timeout == NULL ? NULL : );
. . .


The comparison/contrast for:

> 90692 101629 python2.7   --1  125 sleep   umtxn   
>   



# grep -r '"umtxn"' /usr/src/sys/
/usr/src/sys/kern/kern_umtx.c:  error = umtxq_sleep(uq, 
"umtxn", timeout == NULL ?

/usr/src/sys/kern/kern_umtx.c has:

static int
do_lock_normal(struct thread *td, struct umutex *m, uint32_t flags,
struct _umtx_time *timeout, int mode)
{
. . .
/*
 * We set the contested bit, sleep. Otherwise the lock changed
 * and we need to retry or we lost a race to the thread
 * unlocking the umtx.
 */
umtxq_lock(>uq_key);
umtxq_unbusy(>uq_key);
if (old == owner)
error = umtxq_sleep(uq, "umtxn", timeout == NULL ?
NULL : );
umtxq_remove(uq);
umtxq_unlock(>uq_key);
umtx_key_release(>uq_key);
. . .

Both contexts are umtxq_sleep usage:

/*
 * Put thread into sleep state, before sleeping, check if
 * thread was removed from umtx queue.
 */
static inline int
umtxq_sleep(struct umtx_q *uq, const char *wmesg, struct abs_timeout *abstime)
. . .


Note: I'm guessing that /usr/src/sys/dev/qlnx/qlnxe/ecore_dbg_fw_funcs.c
is not involved.

===
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-unsubscr...@freebsd.org"

Re: Ryzen issues on FreeBSD ?

2018-01-27 Thread Mike Tancsa 
On 1/27/2018 3:23 AM, Don Lewis wrote:
> 
> I just ran into this for this first time with samba46.  I kicked of a
> ports build this evening before leaving for several hours.  When I
> returned, samba46 had failed with a build runaway.  I just tried again
> and I see python stuck in the usem state.  This is what I see with
> procstat -k:

Hmmm, is this indicative of a processor bug or a FreeBSD bug or its
indeterminate at this point ?

> 
>   PIDTID COMMTDNAME  KSTACK   
> 
> 90692 100801 python2.7   -   mi_switch 
> sleepq_catch_signals sleepq_wait_sig _sleep umtxq_sleep do_sem2_wait 
> __umtx_op_sem2_wait amd64_syscall fast_syscall_common 
> 90692 100824 python2.7   -   mi_switch 
> sleepq_catch_signals sleepq_wait_sig _sleep umtxq_sleep do_sem2_wait 
> __umtx_op_sem2_wait amd64_syscall fast_syscall_common 
> 90692 100857 python2.7   -   mi_switch 
> sleepq_catch_signals sleepq_wait_sig _sleep umtxq_sleep do_sem2_wait 
> __umtx_op_sem2_wait amd64_syscall fast_syscall_common 
> 90692 100956 python2.7   -   mi_switch 
> sleepq_catch_signals sleepq_wait_sig _sleep umtxq_sleep do_sem2_wait 
> __umtx_op_sem2_wait amd64_syscall fast_syscall_common 
> 90692 100995 python2.7   -   mi_switch 
> sleepq_catch_signals sleepq_wait_sig _sleep umtxq_sleep do_sem2_wait 
> __umtx_op_sem2_wait amd64_syscall fast_syscall_common 
> 90692 101483 python2.7   -   mi_switch 
> sleepq_catch_signals sleepq_wait_sig _sleep umtxq_sleep do_sem2_wait 
> __umtx_op_sem2_wait amd64_syscall fast_syscall_common 
> 90692 101538 python2.7   -   mi_switch 
> sleepq_catch_signals sleepq_wait_sig _sleep umtxq_sleep do_sem2_wait 
> __umtx_op_sem2_wait amd64_syscall fast_syscall_common 
> 90692 101549 python2.7   -   mi_switch 
> sleepq_catch_signals sleepq_wait_sig _sleep umtxq_sleep do_sem2_wait 
> __umtx_op_sem2_wait amd64_syscall fast_syscall_common 
> 90692 101570 python2.7   -   mi_switch 
> sleepq_catch_signals sleepq_wait_sig _sleep umtxq_sleep do_sem2_wait 
> __umtx_op_sem2_wait amd64_syscall fast_syscall_common 
> 90692 101572 python2.7   -   mi_switch 
> sleepq_catch_signals sleepq_wait_sig _sleep umtxq_sleep do_sem2_wait 
> __umtx_op_sem2_wait amd64_syscall fast_syscall_common 
> 90692 101583 python2.7   -   mi_switch 
> sleepq_catch_signals sleepq_wait_sig _sleep umtxq_sleep do_sem2_wait 
> __umtx_op_sem2_wait amd64_syscall fast_syscall_common 
> 90692 101588 python2.7   -   mi_switch 
> sleepq_catch_signals sleepq_wait_sig _sleep umtxq_sleep do_sem2_wait 
> __umtx_op_sem2_wait amd64_syscall fast_syscall_common 
> 90692 101593 python2.7   -   mi_switch 
> sleepq_catch_signals sleepq_wait_sig _sleep umtxq_sleep do_sem2_wait 
> __umtx_op_sem2_wait amd64_syscall fast_syscall_common 
> 90692 101610 python2.7   -   mi_switch 
> sleepq_catch_signals sleepq_wait_sig _sleep umtxq_sleep do_sem2_wait 
> __umtx_op_sem2_wait amd64_syscall fast_syscall_common 
> 90692 101629 python2.7   -   mi_switch 
> sleepq_catch_signals sleepq_wait_sig _sleep umtxq_sleep do_lock_umutex 
> __umtx_op_wait_umutex amd64_syscall fast_syscall_common 
> 90692 101666 python2.7   -   mi_switch 
> sleepq_catch_signals sleepq_wait_sig _sleep umtxq_sleep do_sem2_wait 
> __umtx_op_sem2_wait amd64_syscall fast_syscall_common 
> 90692 102114 python2.7   -   mi_switch 
> sleepq_catch_signals sleepq_wait_sig _sleep umtxq_sleep do_sem2_wait 
> __umtx_op_sem2_wait amd64_syscall fast_syscall_common 
> 
> and procstat -t:
> 
>   PIDTID COMMTDNAME  CPU  PRI STATE   WCHAN   
>  
> 90692 100801 python2.7   --1  124 sleep   usem
>   
> 90692 100824 python2.7   --1  124 sleep   usem
>   
> 90692 100857 python2.7   --1  124 sleep   usem
>   
> 90692 100956 python2.7   --1  125 sleep   usem
>   
> 90692 100995 python2.7   --1  124 sleep   usem
>   
> 90692 101483 python2.7   --1  124 sleep   usem
>   
> 90692 101538 python2.7   --1  125 sleep   usem
>   
> 90692 101549 python2.7   --1  124 sleep   usem
>   
> 90692 101570 python2.7   --1  124 sleep   usem
>   
> 90692 101572 python2.7   --1  124 sleep   usem
>   
> 90692 101583 python2.7   --1  125 sleep   usem
>   
> 90692 101588 python2.7   --1  124 sleep   usem
>   
>

Re: Ryzen issues on FreeBSD ?

2018-01-27 Thread Don Lewis 
On 23 Jan, Mike Tancsa wrote:
> On 1/22/2018 5:13 PM, Don Lewis wrote:
>> On 22 Jan, Mike Tancsa wrote:
>>> On 1/22/2018 1:41 PM, Peter Moody wrote:
 fwiw, I upgraded to 11-STABLE (11.1-STABLE #6 r328223), applied the
 hw.lower_amd64_sharedpage setting to my loader.conf and got a crash
 last night following the familiar high load -> idle. this was with SMT
 re-enabled. no crashdump, so it was the hard crash that I've been
 getting.
>>>
>>> hw.lower_amd64_sharedpage=1 is the default on AMD boxes no ? I didnt
>>> need to set mine to 1
>>>

 shrug, I'm at a loss here.
>>>
>>> I am trying an RMA with AMD.
>> 
>> Something else that you might want to try is 12.0-CURRENT.  There might
>> be some changes in HEAD that need to be merged back to 11.1-STABLE.
> 
> 
> Temp works as expected now. However, a (similar?) hang building Samba47.
> 
> ctrl+T shows
> 
> 
> load: 1.98  cmd: python2.7 53438 [usem] 54.70r 14.98u 6.04s 0% 230992k
> make: Working in: /usr/ports/net/samba47
> load: 0.34  cmd: python2.7 53438 [usem] 168.48r 14.98u 6.04s 0% 230992k
> make: Working in: /usr/ports/net/samba47
> load: 0.31  cmd: python2.7 53438 [usem] 174.12r 14.98u 6.04s 0% 230992k
> make: Working in: /usr/ports/net/samba47

I just ran into this for this first time with samba46.  I kicked of a
ports build this evening before leaving for several hours.  When I
returned, samba46 had failed with a build runaway.  I just tried again
and I see python stuck in the usem state.  This is what I see with
procstat -k:

  PIDTID COMMTDNAME  KSTACK 
  
90692 100801 python2.7   -   mi_switch 
sleepq_catch_signals sleepq_wait_sig _sleep umtxq_sleep do_sem2_wait 
__umtx_op_sem2_wait amd64_syscall fast_syscall_common 
90692 100824 python2.7   -   mi_switch 
sleepq_catch_signals sleepq_wait_sig _sleep umtxq_sleep do_sem2_wait 
__umtx_op_sem2_wait amd64_syscall fast_syscall_common 
90692 100857 python2.7   -   mi_switch 
sleepq_catch_signals sleepq_wait_sig _sleep umtxq_sleep do_sem2_wait 
__umtx_op_sem2_wait amd64_syscall fast_syscall_common 
90692 100956 python2.7   -   mi_switch 
sleepq_catch_signals sleepq_wait_sig _sleep umtxq_sleep do_sem2_wait 
__umtx_op_sem2_wait amd64_syscall fast_syscall_common 
90692 100995 python2.7   -   mi_switch 
sleepq_catch_signals sleepq_wait_sig _sleep umtxq_sleep do_sem2_wait 
__umtx_op_sem2_wait amd64_syscall fast_syscall_common 
90692 101483 python2.7   -   mi_switch 
sleepq_catch_signals sleepq_wait_sig _sleep umtxq_sleep do_sem2_wait 
__umtx_op_sem2_wait amd64_syscall fast_syscall_common 
90692 101538 python2.7   -   mi_switch 
sleepq_catch_signals sleepq_wait_sig _sleep umtxq_sleep do_sem2_wait 
__umtx_op_sem2_wait amd64_syscall fast_syscall_common 
90692 101549 python2.7   -   mi_switch 
sleepq_catch_signals sleepq_wait_sig _sleep umtxq_sleep do_sem2_wait 
__umtx_op_sem2_wait amd64_syscall fast_syscall_common 
90692 101570 python2.7   -   mi_switch 
sleepq_catch_signals sleepq_wait_sig _sleep umtxq_sleep do_sem2_wait 
__umtx_op_sem2_wait amd64_syscall fast_syscall_common 
90692 101572 python2.7   -   mi_switch 
sleepq_catch_signals sleepq_wait_sig _sleep umtxq_sleep do_sem2_wait 
__umtx_op_sem2_wait amd64_syscall fast_syscall_common 
90692 101583 python2.7   -   mi_switch 
sleepq_catch_signals sleepq_wait_sig _sleep umtxq_sleep do_sem2_wait 
__umtx_op_sem2_wait amd64_syscall fast_syscall_common 
90692 101588 python2.7   -   mi_switch 
sleepq_catch_signals sleepq_wait_sig _sleep umtxq_sleep do_sem2_wait 
__umtx_op_sem2_wait amd64_syscall fast_syscall_common 
90692 101593 python2.7   -   mi_switch 
sleepq_catch_signals sleepq_wait_sig _sleep umtxq_sleep do_sem2_wait 
__umtx_op_sem2_wait amd64_syscall fast_syscall_common 
90692 101610 python2.7   -   mi_switch 
sleepq_catch_signals sleepq_wait_sig _sleep umtxq_sleep do_sem2_wait 
__umtx_op_sem2_wait amd64_syscall fast_syscall_common 
90692 101629 python2.7   -   mi_switch 
sleepq_catch_signals sleepq_wait_sig _sleep umtxq_sleep do_lock_umutex 
__umtx_op_wait_umutex amd64_syscall fast_syscall_common 
90692 101666 python2.7   -   mi_switch 
sleepq_catch_signals sleepq_wait_sig _sleep umtxq_sleep do_sem2_wait 
__umtx_op_sem2_wait amd64_syscall fast_syscall_common 
90692 102114 python2.7   -   mi_switch 
sleepq_catch_signals sleepq_wait_sig _sleep umtxq_sleep do_sem2_wait 
__umtx_op_sem2_wait amd64_syscall fast_syscall_common 

and procstat -t:

  PIDTID COMMTDNAME  CPU  PRI STATE   WCHAN
90692 100801 python2.7   --1  124