Re: Ryzen issues on FreeBSD ? (with sort of workaround)

[Ryan Root]

If you want to use an operating system that takes advantage of CPU to memory 
optimizations without taking steps backwards you have to pay a price.


Sent from my Verizon, Samsung Galaxy smartphone
 Original message From: Don Lewis  Date: 
1/30/18  4:58 PM  (GMT-08:00) To: Mike Tancsa  Cc: Pete French 
, freebsd-stable@freebsd.org, Andriy Gapon 
, Peter Moody , Nimrod Levy 
 Subject: Re: Ryzen issues on FreeBSD ? (with sort of 
workaround) 
On 30 Jan, Mike Tancsa wrote:
> On 1/30/2018 5:23 PM, Nimrod Levy wrote:
>> That's really strange. I never saw those kinds of deadlocks, but I did
>> notice that if I kept the cpu busy using distributed.net
>>  I could keep the full system lockups away for
>> at least a week if not longer.
>> 
>> Not to keep harping on it, but what worked for me was lowering the
>> memory speed. I'm at 11 days of uptime so far without anything running
>> the cpu. Before the change it would lock up anywhere from an hour to a day.
>> 
> Spoke too soon. After a dozen loops, the process has hung again.  Note,
> this is not the box locking up, just the compile.  I do have memory at a
> lower speed too. -- 2133 instead of the default 2400

I suspect the problem is a race condition that causes a wakeup to be
lost.  Adding load changes the timing enough to avoid the problem most
of the time.

> I also just tried upgrading to the latest HEAD with a generic kernel and
> same / similar lockups although procstat -kk gives some odd results
> 
> 
> root@amdtestr12:/home/mdtancsa # procstat -kk 6067
>   PID    TID COMM    TDNAME  KSTACK
> 
>  6067 100865 python2.7   -   ??+0 ??+0 ??+0 ??+0
> ??+0 ??+0 ??+0 ??+0 ??+0 ??+0
>  6067 100900 python2.7   -   ??+0 ??+0 ??+0 ??+0
> ??+0 ??+0 ??+0 ??+0 ??+0 ??+0
>  6067 100901 python2.7   -   ??+0 ??+0 ??+0 ??+0
> ??+0 ??+0 ??+0 ??+0 ??+0 ??+0
>  6067 100902 python2.7   -   ??+0 ??+0 ??+0 ??+0
> ??+0 ??+0 ??+0 ??+0 ??+0 ??+0
>  6067 100903 python2.7   -   ??+0 ??+0 ??+0 ??+0
> ??+0 ??+0 ??+0 ??+0 ??+0 ??+0
>  6067 100904 python2.7   -   ??+0 ??+0 ??+0 ??+0
> ??+0 ??+0 ??+0 ??+0 ??+0 ??+0
>  6067 100905 python2.7   -   ??+0 ??+0 ??+0 ??+0
> ??+0 ??+0 ??+0 ??+0 ??+0 ??+0
>  6067 100906 python2.7   -   ??+0 ??+0 ??+0 ??+0
> ??+0 ??+0 ??+0 ??+0 ??+0 ??+0
>  6067 100907 python2.7   -   ??+0 ??+0 ??+0 ??+0
> ??+0 ??+0 ??+0 ??+0 ??+0 ??+0
>  6067 100908 python2.7   -   ??+0 ??+0 ??+0 ??+0
> ??+0 ??+0 ??+0 ??+0 ??+0 ??+0
>  6067 100909 python2.7   -   ??+0 ??+0 ??+0 ??+0
> ??+0 ??+0 ??+0 ??+0 ??+0 ??+0
>  6067 100910 python2.7   -   ??+0 ??+0 ??+0 ??+0
> ??+0 ??+0 ??+0 ??+0 ??+0 ??+0
>  6067 100911 python2.7   -   ??+0 ??+0 ??+0 ??+0
> ??+0 ??+0 ??+0 ??+0 ??+0 ??+0

Strange ... kernel vs. world mismatch?  Some other new regression in
HEAD?


___
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"
___
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 ? (with sort of workaround)

[Don Lewis]

On 30 Jan, Mike Tancsa wrote:
> On 1/30/2018 5:23 PM, Nimrod Levy wrote:
>> That's really strange. I never saw those kinds of deadlocks, but I did
>> notice that if I kept the cpu busy using distributed.net
>>  I could keep the full system lockups away for
>> at least a week if not longer.
>> 
>> Not to keep harping on it, but what worked for me was lowering the
>> memory speed. I'm at 11 days of uptime so far without anything running
>> the cpu. Before the change it would lock up anywhere from an hour to a day.
>> 
> Spoke too soon. After a dozen loops, the process has hung again.  Note,
> this is not the box locking up, just the compile.  I do have memory at a
> lower speed too. -- 2133 instead of the default 2400

I suspect the problem is a race condition that causes a wakeup to be
lost.  Adding load changes the timing enough to avoid the problem most
of the time.

> I also just tried upgrading to the latest HEAD with a generic kernel and
> same / similar lockups although procstat -kk gives some odd results
> 
> 
> root@amdtestr12:/home/mdtancsa # procstat -kk 6067
>   PIDTID COMMTDNAME  KSTACK
> 
>  6067 100865 python2.7   -   ??+0 ??+0 ??+0 ??+0
> ??+0 ??+0 ??+0 ??+0 ??+0 ??+0
>  6067 100900 python2.7   -   ??+0 ??+0 ??+0 ??+0
> ??+0 ??+0 ??+0 ??+0 ??+0 ??+0
>  6067 100901 python2.7   -   ??+0 ??+0 ??+0 ??+0
> ??+0 ??+0 ??+0 ??+0 ??+0 ??+0
>  6067 100902 python2.7   -   ??+0 ??+0 ??+0 ??+0
> ??+0 ??+0 ??+0 ??+0 ??+0 ??+0
>  6067 100903 python2.7   -   ??+0 ??+0 ??+0 ??+0
> ??+0 ??+0 ??+0 ??+0 ??+0 ??+0
>  6067 100904 python2.7   -   ??+0 ??+0 ??+0 ??+0
> ??+0 ??+0 ??+0 ??+0 ??+0 ??+0
>  6067 100905 python2.7   -   ??+0 ??+0 ??+0 ??+0
> ??+0 ??+0 ??+0 ??+0 ??+0 ??+0
>  6067 100906 python2.7   -   ??+0 ??+0 ??+0 ??+0
> ??+0 ??+0 ??+0 ??+0 ??+0 ??+0
>  6067 100907 python2.7   -   ??+0 ??+0 ??+0 ??+0
> ??+0 ??+0 ??+0 ??+0 ??+0 ??+0
>  6067 100908 python2.7   -   ??+0 ??+0 ??+0 ??+0
> ??+0 ??+0 ??+0 ??+0 ??+0 ??+0
>  6067 100909 python2.7   -   ??+0 ??+0 ??+0 ??+0
> ??+0 ??+0 ??+0 ??+0 ??+0 ??+0
>  6067 100910 python2.7   -   ??+0 ??+0 ??+0 ??+0
> ??+0 ??+0 ??+0 ??+0 ??+0 ??+0
>  6067 100911 python2.7   -   ??+0 ??+0 ??+0 ??+0
> ??+0 ??+0 ??+0 ??+0 ??+0 ??+0

Strange ... kernel vs. world mismatch?  Some other new regression in
HEAD?


___
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 ? (with sort of workaround)

[Mike Tancsa]

On 1/30/2018 5:23 PM, Nimrod Levy wrote:
> That's really strange. I never saw those kinds of deadlocks, but I did
> notice that if I kept the cpu busy using distributed.net
>  I could keep the full system lockups away for
> at least a week if not longer.
> 
> Not to keep harping on it, but what worked for me was lowering the
> memory speed. I'm at 11 days of uptime so far without anything running
> the cpu. Before the change it would lock up anywhere from an hour to a day.
> 
Spoke too soon. After a dozen loops, the process has hung again.  Note,
this is not the box locking up, just the compile.  I do have memory at a
lower speed too. -- 2133 instead of the default 2400


I also just tried upgrading to the latest HEAD with a generic kernel and
same / similar lockups although procstat -kk gives some odd results


root@amdtestr12:/home/mdtancsa # procstat -kk 6067
  PIDTID COMMTDNAME  KSTACK

 6067 100865 python2.7   -   ??+0 ??+0 ??+0 ??+0
??+0 ??+0 ??+0 ??+0 ??+0 ??+0
 6067 100900 python2.7   -   ??+0 ??+0 ??+0 ??+0
??+0 ??+0 ??+0 ??+0 ??+0 ??+0
 6067 100901 python2.7   -   ??+0 ??+0 ??+0 ??+0
??+0 ??+0 ??+0 ??+0 ??+0 ??+0
 6067 100902 python2.7   -   ??+0 ??+0 ??+0 ??+0
??+0 ??+0 ??+0 ??+0 ??+0 ??+0
 6067 100903 python2.7   -   ??+0 ??+0 ??+0 ??+0
??+0 ??+0 ??+0 ??+0 ??+0 ??+0
 6067 100904 python2.7   -   ??+0 ??+0 ??+0 ??+0
??+0 ??+0 ??+0 ??+0 ??+0 ??+0
 6067 100905 python2.7   -   ??+0 ??+0 ??+0 ??+0
??+0 ??+0 ??+0 ??+0 ??+0 ??+0
 6067 100906 python2.7   -   ??+0 ??+0 ??+0 ??+0
??+0 ??+0 ??+0 ??+0 ??+0 ??+0
 6067 100907 python2.7   -   ??+0 ??+0 ??+0 ??+0
??+0 ??+0 ??+0 ??+0 ??+0 ??+0
 6067 100908 python2.7   -   ??+0 ??+0 ??+0 ??+0
??+0 ??+0 ??+0 ??+0 ??+0 ??+0
 6067 100909 python2.7   -   ??+0 ??+0 ??+0 ??+0
??+0 ??+0 ??+0 ??+0 ??+0 ??+0
 6067 100910 python2.7   -   ??+0 ??+0 ??+0 ??+0
??+0 ??+0 ??+0 ??+0 ??+0 ??+0
 6067 100911 python2.7   -   ??+0 ??+0 ??+0 ??+0
??+0 ??+0 ??+0 ??+0 ??+0 ??+0
root@amdtestr12:/home/mdtancsa # procstat -t 6067
  PIDTID COMMTDNAME  CPU  PRI STATE
WCHAN
 6067 100865 python2.7   --1  152 sleep
usem
 6067 100900 python2.7   --1  152 sleep
umtxn
 6067 100901 python2.7   --1  152 sleep
umtxn
 6067 100902 python2.7   --1  152 sleep
umtxn
 6067 100903 python2.7   --1  152 sleep
umtxn
 6067 100904 python2.7   --1  152 sleep
umtxn
 6067 100905 python2.7   --1  152 sleep
umtxn
 6067 100906 python2.7   --1  152 sleep
umtxn
 6067 100907 python2.7   --1  152 sleep
umtxn
 6067 100908 python2.7   --1  152 sleep
umtxn
 6067 100909 python2.7   --1  152 sleep
umtxn
 6067 100910 python2.7   --1  152 sleep
umtxn
 6067 100911 python2.7   --1  152 sleep
umtxn
root@amdtestr12:/home/mdtancsa #


-- 
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada
___
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 ? (with sort of workaround)

[Don Lewis]

On 30 Jan, Mike Tancsa wrote:
> On 1/30/2018 2:51 PM, Mike Tancsa wrote:
>> 
>> And sadly, I am still able to hang the compile in about the same place.
>> However, if I set
> 
> 
> OK, here is a sort of work around. If I have the box a little more busy,
> I can avoid whatever deadlock is going on.  In another console I have
> cat /dev/urandom | sha256
> running while the build runs

Interesting ...

> ... and I can compile net/samba47 from scratch without the compile
> hanging.  This problem also happens on HEAD from today.  Should I start
> a new thread on freebsd-current ? Or just file a bug report ?
> The compile worked 4/4

I'd file a PR to capture all the information in one place and drop a
pointer on freebsd-current.

___
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 ? (with sort of workaround)

[Nimrod Levy]

That's really strange. I never saw those kinds of deadlocks, but I did
notice that if I kept the cpu busy using distributed.net I could keep the
full system lockups away for at least a week if not longer.

Not to keep harping on it, but what worked for me was lowering the memory
speed. I'm at 11 days of uptime so far without anything running the cpu.
Before the change it would lock up anywhere from an hour to a day.


On Tue, Jan 30, 2018 at 4:39 PM Mike Tancsa  wrote:

> On 1/30/2018 2:51 PM, Mike Tancsa wrote:
> >
> > And sadly, I am still able to hang the compile in about the same place.
> > However, if I set
>
>
> OK, here is a sort of work around. If I have the box a little more busy,
> I can avoid whatever deadlock is going on.  In another console I have
> cat /dev/urandom | sha256
> running while the build runs
>
> ... and I can compile net/samba47 from scratch without the compile
> hanging.  This problem also happens on HEAD from today.  Should I start
> a new thread on freebsd-current ? Or just file a bug report ?
> The compile worked 4/4
>
> ---Mike
>
>
>
>
>
>
>
>
>
>
> >
> > hw.lower_amd64_sharedpage=0
> >
> > it seems to hang in a different way. CTRL+t shows
> >
> > load: 0.43  cmd: python2.7 15736 [umtxn] 165.00r 14.46u 6.65s 0% 233600k
> > make[1]: Working in: /usr/ports/net/samba47
> > make: Working in: /usr/ports/net/samba47
> >
> >
> > # procstat -t 15736
> >   PIDTID COMMTDNAME  CPU  PRI STATE
> > WCHAN
> > 15736 100855 python2.7   --1  152 sleep
> > usem
> > 15736 100956 python2.7   --1  124 sleep
> > umtxn
> > 15736 100957 python2.7   --1  126 sleep
> > umtxn
> > 15736 100958 python2.7   --1  124 sleep
> > umtxn
> > 15736 100959 python2.7   --1  127 sleep
> > umtxn
> > 15736 100960 python2.7   --1  126 sleep
> > umtxn
> > 15736 100961 python2.7   --1  126 sleep
> > umtxn
> > 15736 100962 python2.7   --1  126 sleep
> > umtxn
> > 15736 100963 python2.7   --1  126 sleep
> > umtxn
> > 15736 100964 python2.7   --1  127 sleep
> > umtxn
> > 15736 100965 python2.7   --1  126 sleep
> > umtxn
> > 15736 100966 python2.7   --1  126 sleep
> > umtxn
> > 15736 100967 python2.7   --1  126 sleep
> > umtxn
> >
> >  # procstat -kk 15736
> >   PIDTID COMMTDNAME  KSTACK
> >
> > 15736 100855 python2.7   -   mi_switch+0xf5
> > sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231
> > umtxq_sleep+0x143 do_sem2_wait+0x68a __umtx_op_sem2_wait+0x4b
> > amd64_syscall+0xa48 fast_syscall_common+0xfc
> > 15736 100956 python2.7   -   mi_switch+0xf5
> > sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231
> > umtxq_sleep+0x143 do_lock_umutex+0x885 __umtx_op_wait_umutex+0x48
> > amd64_syscall+0xa48 fast_syscall_common+0xfc
> > 15736 100957 python2.7   -   mi_switch+0xf5
> > sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231
> > umtxq_sleep+0x143 do_lock_umutex+0x885 __umtx_op_wait_umutex+0x48
> > amd64_syscall+0xa48 fast_syscall_common+0xfc
> > 15736 100958 python2.7   -   mi_switch+0xf5
> > sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231
> > umtxq_sleep+0x143 do_lock_umutex+0x885 __umtx_op_wait_umutex+0x48
> > amd64_syscall+0xa48 fast_syscall_common+0xfc
> > 15736 100959 python2.7   -   mi_switch+0xf5
> > sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231
> > umtxq_sleep+0x143 do_lock_umutex+0x885 __umtx_op_wait_umutex+0x48
> > amd64_syscall+0xa48 fast_syscall_common+0xfc
> > 15736 100960 python2.7   -   mi_switch+0xf5
> > sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231
> > umtxq_sleep+0x143 do_lock_umutex+0x885 __umtx_op_wait_umutex+0x48
> > amd64_syscall+0xa48 fast_syscall_common+0xfc
> > 15736 100961 python2.7   -   mi_switch+0xf5
> > sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231
> > umtxq_sleep+0x143 do_lock_umutex+0x885 __umtx_op_wait_umutex+0x48
> > amd64_syscall+0xa48 fast_syscall_common+0xfc
> > 15736 100962 python2.7   -   mi_switch+0xf5
> > sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231
> > umtxq_sleep+0x143 do_lock_umutex+0x885 __umtx_op_wait_umutex+0x48
> > amd64_syscall+0xa48 fast_syscall_common+0xfc
> > 15736 100963 python2.7   -   mi_switch+0xf5
> > sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231
> > umtxq_sleep+0x143 do_lock_umutex+0x885 __umtx_op_wait_umutex+0x48
> > amd64_syscall+0xa48 fast_syscall_common+0xfc
> > 15736 100964 python2.7   -

Re: Ryzen issues on FreeBSD ? (with sort of workaround)

[Mike Tancsa]

On 1/30/2018 2:51 PM, Mike Tancsa wrote:
> 
> And sadly, I am still able to hang the compile in about the same place.
> However, if I set


OK, here is a sort of work around. If I have the box a little more busy,
I can avoid whatever deadlock is going on.  In another console I have
cat /dev/urandom | sha256
running while the build runs

... and I can compile net/samba47 from scratch without the compile
hanging.  This problem also happens on HEAD from today.  Should I start
a new thread on freebsd-current ? Or just file a bug report ?
The compile worked 4/4

---Mike










> 
> hw.lower_amd64_sharedpage=0
> 
> it seems to hang in a different way. CTRL+t shows
> 
> load: 0.43  cmd: python2.7 15736 [umtxn] 165.00r 14.46u 6.65s 0% 233600k
> make[1]: Working in: /usr/ports/net/samba47
> make: Working in: /usr/ports/net/samba47
> 
> 
> # procstat -t 15736
>   PIDTID COMMTDNAME  CPU  PRI STATE
> WCHAN
> 15736 100855 python2.7   --1  152 sleep
> usem
> 15736 100956 python2.7   --1  124 sleep
> umtxn
> 15736 100957 python2.7   --1  126 sleep
> umtxn
> 15736 100958 python2.7   --1  124 sleep
> umtxn
> 15736 100959 python2.7   --1  127 sleep
> umtxn
> 15736 100960 python2.7   --1  126 sleep
> umtxn
> 15736 100961 python2.7   --1  126 sleep
> umtxn
> 15736 100962 python2.7   --1  126 sleep
> umtxn
> 15736 100963 python2.7   --1  126 sleep
> umtxn
> 15736 100964 python2.7   --1  127 sleep
> umtxn
> 15736 100965 python2.7   --1  126 sleep
> umtxn
> 15736 100966 python2.7   --1  126 sleep
> umtxn
> 15736 100967 python2.7   --1  126 sleep
> umtxn
> 
>  # procstat -kk 15736
>   PIDTID COMMTDNAME  KSTACK
> 
> 15736 100855 python2.7   -   mi_switch+0xf5
> sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231
> umtxq_sleep+0x143 do_sem2_wait+0x68a __umtx_op_sem2_wait+0x4b
> amd64_syscall+0xa48 fast_syscall_common+0xfc
> 15736 100956 python2.7   -   mi_switch+0xf5
> sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231
> umtxq_sleep+0x143 do_lock_umutex+0x885 __umtx_op_wait_umutex+0x48
> amd64_syscall+0xa48 fast_syscall_common+0xfc
> 15736 100957 python2.7   -   mi_switch+0xf5
> sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231
> umtxq_sleep+0x143 do_lock_umutex+0x885 __umtx_op_wait_umutex+0x48
> amd64_syscall+0xa48 fast_syscall_common+0xfc
> 15736 100958 python2.7   -   mi_switch+0xf5
> sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231
> umtxq_sleep+0x143 do_lock_umutex+0x885 __umtx_op_wait_umutex+0x48
> amd64_syscall+0xa48 fast_syscall_common+0xfc
> 15736 100959 python2.7   -   mi_switch+0xf5
> sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231
> umtxq_sleep+0x143 do_lock_umutex+0x885 __umtx_op_wait_umutex+0x48
> amd64_syscall+0xa48 fast_syscall_common+0xfc
> 15736 100960 python2.7   -   mi_switch+0xf5
> sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231
> umtxq_sleep+0x143 do_lock_umutex+0x885 __umtx_op_wait_umutex+0x48
> amd64_syscall+0xa48 fast_syscall_common+0xfc
> 15736 100961 python2.7   -   mi_switch+0xf5
> sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231
> umtxq_sleep+0x143 do_lock_umutex+0x885 __umtx_op_wait_umutex+0x48
> amd64_syscall+0xa48 fast_syscall_common+0xfc
> 15736 100962 python2.7   -   mi_switch+0xf5
> sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231
> umtxq_sleep+0x143 do_lock_umutex+0x885 __umtx_op_wait_umutex+0x48
> amd64_syscall+0xa48 fast_syscall_common+0xfc
> 15736 100963 python2.7   -   mi_switch+0xf5
> sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231
> umtxq_sleep+0x143 do_lock_umutex+0x885 __umtx_op_wait_umutex+0x48
> amd64_syscall+0xa48 fast_syscall_common+0xfc
> 15736 100964 python2.7   -   mi_switch+0xf5
> sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231
> umtxq_sleep+0x143 do_lock_umutex+0x885 __umtx_op_wait_umutex+0x48
> amd64_syscall+0xa48 fast_syscall_common+0xfc
> 15736 100965 python2.7   -   mi_switch+0xf5
> sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231
> umtxq_sleep+0x143 do_lock_umutex+0x885 __umtx_op_wait_umutex+0x48
> amd64_syscall+0xa48 fast_syscall_common+0xfc
> 15736 100966 python2.7   -   mi_switch+0xf5
> sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231
> umtxq_sleep+0x143 do_lock_umutex+0x885 __umtx_op_wait_umutex+0x48
> amd64_syscall+0xa48 

Re: Ryzen issues on FreeBSD ?

[Mike Tancsa]

On 1/28/2018 7:41 PM, Don Lewis wrote:
> 
> My suspicion is a FreeBSD bug, probably a locking / race issue.  I know
> that we've had to make some tweeks to our code for AMD CPUs, like this:


OK, I got back the CPUs from AMD (fast turn around!)

And sadly, I am still able to hang the compile in about the same place.
However, if I set

hw.lower_amd64_sharedpage=0

it seems to hang in a different way. CTRL+t shows

load: 0.43  cmd: python2.7 15736 [umtxn] 165.00r 14.46u 6.65s 0% 233600k
make[1]: Working in: /usr/ports/net/samba47
make: Working in: /usr/ports/net/samba47


# procstat -t 15736
  PIDTID COMMTDNAME  CPU  PRI STATE
WCHAN
15736 100855 python2.7   --1  152 sleep
usem
15736 100956 python2.7   --1  124 sleep
umtxn
15736 100957 python2.7   --1  126 sleep
umtxn
15736 100958 python2.7   --1  124 sleep
umtxn
15736 100959 python2.7   --1  127 sleep
umtxn
15736 100960 python2.7   --1  126 sleep
umtxn
15736 100961 python2.7   --1  126 sleep
umtxn
15736 100962 python2.7   --1  126 sleep
umtxn
15736 100963 python2.7   --1  126 sleep
umtxn
15736 100964 python2.7   --1  127 sleep
umtxn
15736 100965 python2.7   --1  126 sleep
umtxn
15736 100966 python2.7   --1  126 sleep
umtxn
15736 100967 python2.7   --1  126 sleep
umtxn

 # procstat -kk 15736
  PIDTID COMMTDNAME  KSTACK

15736 100855 python2.7   -   mi_switch+0xf5
sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231
umtxq_sleep+0x143 do_sem2_wait+0x68a __umtx_op_sem2_wait+0x4b
amd64_syscall+0xa48 fast_syscall_common+0xfc
15736 100956 python2.7   -   mi_switch+0xf5
sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231
umtxq_sleep+0x143 do_lock_umutex+0x885 __umtx_op_wait_umutex+0x48
amd64_syscall+0xa48 fast_syscall_common+0xfc
15736 100957 python2.7   -   mi_switch+0xf5
sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231
umtxq_sleep+0x143 do_lock_umutex+0x885 __umtx_op_wait_umutex+0x48
amd64_syscall+0xa48 fast_syscall_common+0xfc
15736 100958 python2.7   -   mi_switch+0xf5
sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231
umtxq_sleep+0x143 do_lock_umutex+0x885 __umtx_op_wait_umutex+0x48
amd64_syscall+0xa48 fast_syscall_common+0xfc
15736 100959 python2.7   -   mi_switch+0xf5
sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231
umtxq_sleep+0x143 do_lock_umutex+0x885 __umtx_op_wait_umutex+0x48
amd64_syscall+0xa48 fast_syscall_common+0xfc
15736 100960 python2.7   -   mi_switch+0xf5
sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231
umtxq_sleep+0x143 do_lock_umutex+0x885 __umtx_op_wait_umutex+0x48
amd64_syscall+0xa48 fast_syscall_common+0xfc
15736 100961 python2.7   -   mi_switch+0xf5
sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231
umtxq_sleep+0x143 do_lock_umutex+0x885 __umtx_op_wait_umutex+0x48
amd64_syscall+0xa48 fast_syscall_common+0xfc
15736 100962 python2.7   -   mi_switch+0xf5
sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231
umtxq_sleep+0x143 do_lock_umutex+0x885 __umtx_op_wait_umutex+0x48
amd64_syscall+0xa48 fast_syscall_common+0xfc
15736 100963 python2.7   -   mi_switch+0xf5
sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231
umtxq_sleep+0x143 do_lock_umutex+0x885 __umtx_op_wait_umutex+0x48
amd64_syscall+0xa48 fast_syscall_common+0xfc
15736 100964 python2.7   -   mi_switch+0xf5
sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231
umtxq_sleep+0x143 do_lock_umutex+0x885 __umtx_op_wait_umutex+0x48
amd64_syscall+0xa48 fast_syscall_common+0xfc
15736 100965 python2.7   -   mi_switch+0xf5
sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231
umtxq_sleep+0x143 do_lock_umutex+0x885 __umtx_op_wait_umutex+0x48
amd64_syscall+0xa48 fast_syscall_common+0xfc
15736 100966 python2.7   -   mi_switch+0xf5
sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231
umtxq_sleep+0x143 do_lock_umutex+0x885 __umtx_op_wait_umutex+0x48
amd64_syscall+0xa48 fast_syscall_common+0xfc
15736 100967 python2.7   -   mi_switch+0xf5
sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231
umtxq_sleep+0x143 do_lock_umutex+0x885 __umtx_op_wait_umutex+0x48
amd64_syscall+0xa48 fast_syscall_common+0xfc

If I kill the make, reboot and just type make, it completes after the
reboot.  If after the reboot, I do an rm -R work, it will hang again.
With the default of

Re: i386 with 4GB RAM: less than 2GB available on A2SAV (Intel Atom E3940)

[Brooks Davis]

On Tue, Jan 30, 2018 at 07:09:44AM -0700, Alan Somers wrote:
> On Tue, Jan 30, 2018 at 12:11 AM, Andre Albsmeier <
> andre.albsme...@siemens.com> wrote:
> 
> > On Sun, 28-Jan-2018 at 10:32:44 -0600, Mike Karels wrote:
> > > > On 28 Jan 2018, at 15:57, Andre Albsmeier 
> > =
> > > > wrote:
> > > > > I have a lot of machines running with 4 GB physical RAM and, for
> > > > > some reasons, I still have to use a 32 bits OS.
> > > > >=20
> > > > > All of them show something between 3 and 3.5 GB of RAM available
> > > > > in dmesg but the brand new Supermicro A2SAV really shocked me:
> > > > >=20
> > > > > FreeBSD 11.1-STABLE #0: Mon Jan 15 06:57:10 CET 2018
> > > > > ...
> > > > > real memory  =3D 4294967296 (4096 MB)
> > > > > avail memory =3D 1939558400 (1849 MB)
> > > > > ...
> > > > >=20
> > > > > So do people have any ideas how I might get a bit closer to at least
> > > > > 3 GB? I assume there are no FreeBSD knobs which might help but hope
> > > > > dies last...
> > >
> > > > This is a common problem on i386.  Most likely some ranges are reserved
> > > > for I/O mappings, such as video cards.  If you boot with -v, I think
> > the
> > > > kernel prints an overview of the physical ram chunks available?  I
> > don't
> > > > know of any other way to get such an overview.
> > >
> > > > Another option is to try PAE, but I have no idea how stable that is...
> > >
> > > > -Dimitry
> > >
> > > I suspect that the unavailable RAM has been mapped above 4 GB by the
> > BIOS.
> > >
> > > About PAE: at $JOB, we have a FreeBSD 8.2 system that has been running
> > > PAE reliably since 8.2 was new.  Also, we ship amd64 systems that run
> > > mostly 32-bit binaries, which works well.
> >
> > But can the entire userland be 32 bit only?
> 
> Sure.  I do this with jails.  It's no problem to have a 32-bit jail on a
> 64-bit kernel.  Kernel modules would be an issue, though.  If you need any,
> you'll have to find a way for the 64-bit machines to find 64-bit kernel
> modules.

There are some deficiencies in the management space[0], but it should
generally work.  Where it doesn't it's a bug and usually not too hard to
fix.

-- Brooks

[0] e.g. https://reviews.freebsd.org/D13459


signature.asc
Description: PGP signature

Improve the web presence of your business

[Jennifer Anderson]

Greetings,

 

Let's work together!

 

We are a trusted digital marketing agency for more than 10 years, our team
of 200+ marketing gurus has served over 4000 clients. Our unique
"Pay-for-performance" model attracts customers from all geographies of the
world, and we are proud to cater to the needs of every type of business
belonging to varied industries, scales, and regions. 

 

We do "Pay-For-Performance SEO" service, Pay only when we rank your keywords
on Top searches. 

 

-  FREE website analysis report

-  No monthly fee / No contractual payout

-  Dedicated 24*7 support

-  Only one time set up fee 

 

Our results 'Talk' 

 

Get your website evaluated NOW, Just reply to this email with your contact
details along with your requirement and we will call you back.




Thanks & Regards,

Jennifer Anderson 
Marketing Manager
Head Office: San Jose, CA 95120 

 

 

 

Disclaimer: We are not spamming. We are using this domain for marketing. If
you are interested and want to know about us, just reply to this email. If
we have offended you by sending this to you by mistake, we apologize. Please
reply "NO" or "Unsubscribe" to this email if not interested, so that we
shall add you to our "Do Not Contact Again" list. We strictly adhere to
United States Federal Laws of Anti-spamming - CAN-SPAM Act of 2003.

___
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: i386 with 4GB RAM: less than 2GB available on A2SAV (Intel Atom E3940)

[Konstantin Belousov]

On Tue, Jan 30, 2018 at 07:54:41AM -0600, Mike Karels wrote:
> > On 30.01.2018 13:59, Andre Albsmeier wrote:
> 
> > >> Also, I'd like to know reasons that made you stick to 32 bit OS
> > >> as we have pretty good support for 32 bit applications running under 64 
> > >> bit system.
> > > 
> > > I (still) have 32 bit machines and don't want to maintain 2 userlands.
> > > Each machine has its own kernel but userland (updated via nfs) must
> > > remain 32 bit.
> > > 
> > > Or is it possible to boot a 64 bit kernel and have everything else in
> > > 32 bit?
> 
> > I have not tried "everything else in 32 bit", there may be some rough edges
> > dealing with run-time linker but you can try.
> 
> > /sbin/init is statically linked and it should work with kernel having 
> > option COMPAT_FREEBSD32.
> > /bin/sh may be OK too provided /libexec/ld-elf32.so.1 is in place.
> 
> > You should really consider switching to 64 bit kernel for such hardware.
> 
> You definitely cannot run all of userland in 32-bit mode.  There are many
> sysadin programs that have incompatible syscall interfaces, starting with
> mount, ifconfig, ps, route, netstat, etc (probably 50 total).  Unless they
> were all statically linked, you would have to install the 64-bit shared
> libraries, moving the 32-bit libraries to /lib32 and /usr/lib32, and
> switching around /libexec/ld-elf*.
ps(8) compatibility for compat32 is nearly perfect, mount (in its nmount
syscall variant) also works. There is no issue with /libexec/ld-elf.so.1
being 32bit, whatever rumors whoever tried to spread.

Yes, networking administrative interfaces are not functional for compat32.
This precludes both ifconfig(8) and route(8) from operating.  Also, firewall
management tools, for all three FreeBSD firewalls, can only work with
matching kernel.

> 
> Or, if you really want the userland to be the same, you could use a PAE
> kernel.
> 
>   Mike
> ___
> 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"
___
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: i386 with 4GB RAM: less than 2GB available on A2SAV (Intel Atom E3940)

[Alan Somers]

On Tue, Jan 30, 2018 at 12:11 AM, Andre Albsmeier <
andre.albsme...@siemens.com> wrote:

> On Sun, 28-Jan-2018 at 10:32:44 -0600, Mike Karels wrote:
> > > On 28 Jan 2018, at 15:57, Andre Albsmeier 
> =
> > > wrote:
> > > > I have a lot of machines running with 4 GB physical RAM and, for
> > > > some reasons, I still have to use a 32 bits OS.
> > > >=20
> > > > All of them show something between 3 and 3.5 GB of RAM available
> > > > in dmesg but the brand new Supermicro A2SAV really shocked me:
> > > >=20
> > > > FreeBSD 11.1-STABLE #0: Mon Jan 15 06:57:10 CET 2018
> > > > ...
> > > > real memory  =3D 4294967296 (4096 MB)
> > > > avail memory =3D 1939558400 (1849 MB)
> > > > ...
> > > >=20
> > > > So do people have any ideas how I might get a bit closer to at least
> > > > 3 GB? I assume there are no FreeBSD knobs which might help but hope
> > > > dies last...
> >
> > > This is a common problem on i386.  Most likely some ranges are reserved
> > > for I/O mappings, such as video cards.  If you boot with -v, I think
> the
> > > kernel prints an overview of the physical ram chunks available?  I
> don't
> > > know of any other way to get such an overview.
> >
> > > Another option is to try PAE, but I have no idea how stable that is...
> >
> > > -Dimitry
> >
> > I suspect that the unavailable RAM has been mapped above 4 GB by the
> BIOS.
> >
> > About PAE: at $JOB, we have a FreeBSD 8.2 system that has been running
> > PAE reliably since 8.2 was new.  Also, we ship amd64 systems that run
> > mostly 32-bit binaries, which works well.
>
> But can the entire userland be 32 bit only?
>

Sure.  I do this with jails.  It's no problem to have a 32-bit jail on a
64-bit kernel.  Kernel modules would be an issue, though.  If you need any,
you'll have to find a way for the 64-bit machines to find 64-bit kernel
modules.


>
> Maybe I'll try the PAE thing...
>
___
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: i386 with 4GB RAM: less than 2GB available on A2SAV (Intel Atom E3940)

[Mike Karels]

> On 30.01.2018 13:59, Andre Albsmeier wrote:

> >> Also, I'd like to know reasons that made you stick to 32 bit OS
> >> as we have pretty good support for 32 bit applications running under 64 
> >> bit system.
> > 
> > I (still) have 32 bit machines and don't want to maintain 2 userlands.
> > Each machine has its own kernel but userland (updated via nfs) must
> > remain 32 bit.
> > 
> > Or is it possible to boot a 64 bit kernel and have everything else in
> > 32 bit?

> I have not tried "everything else in 32 bit", there may be some rough edges
> dealing with run-time linker but you can try.

> /sbin/init is statically linked and it should work with kernel having option 
> COMPAT_FREEBSD32.
> /bin/sh may be OK too provided /libexec/ld-elf32.so.1 is in place.

> You should really consider switching to 64 bit kernel for such hardware.

You definitely cannot run all of userland in 32-bit mode.  There are many
sysadin programs that have incompatible syscall interfaces, starting with
mount, ifconfig, ps, route, netstat, etc (probably 50 total).  Unless they
were all statically linked, you would have to install the 64-bit shared
libraries, moving the 32-bit libraries to /lib32 and /usr/lib32, and
switching around /libexec/ld-elf*.

Or, if you really want the userland to be the same, you could use a PAE
kernel.

Mike
___
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"

[Bug 221146] [ixgbe] Problem with second laggport

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221146

Peter Vanek  changed:

   What|Removed |Added

 CC||p...@efficientip.com

--- Comment #22 from Peter Vanek  ---
Hello,

I would like to add little piece to this as well.
We can reproduce same issue with driver 3.2.12-k 

Jan 30 12:59:18 localhost ix0:  port 0xecc0-0xecdf mem
0xd9d0-0xd9df,0xd9ff8000-0xd9ffbfff irq 40 at device 0.0 numa-domain 0
on pci2

having lagg1

lagg1: flags=8843 metric 0 mtu 1500
   
options=e407b9
ether a0:36:9f:3e:57:18
inet 61.0.0.24 netmask 0xff00 broadcast 61.255.255.255
nd6 options=29
media: Ethernet autoselect
status: active
groups: lagg
laggproto failover lagghash l2,l3,l4
laggport: ix0 flags=5
laggport: ix1 flags=0<>


we use simple script to reproduce this:

# more a.sh
#!/bin/sh

while true; do
ifconfig $1 down
echo next $1
ifconfig $1 up
#sleep 1
done


# sh a.sh ix0


After about 30-50 loops, we can find ix0 interface with flag UP, but with 'no
carrier' status

ix0: flags=8843 metric 0 mtu 1500
   
options=9400b8
ether a0:36:9f:3e:57:18
hwaddr a0:36:9f:3e:57:18
nd6 options=29
media: Ethernet autoselect
status: no carrier
plugged: SFP/SFP+/SFP28 10G Base-SR (LC)
vendor: OEM PN: SFP-10G-SR SN: IN140317016 DATE: 2014-03-20
module temperature: 30.60 C Voltage: 3.29 Volts
RX: 0.38 mW (-4.10 dBm) TX: 0.41 mW (-3.85 dBm)

SFF8472 DUMP (0xA0 0..127 range):
03 04 07 10 00 00 50 FF 00 00 00 06 67 02 00 00
08 03 00 1E 4F 45 4D 20 20 20 20 20 20 20 20 20
20 20 20 20 00 00 1B 21 53 46 50 2D 31 30 47 2D
53 52 20 20 20 20 20 20 41 20 20 20 03 52 00 BA
00 3A 00 00 49 4E 31 34 30 33 31 37 30 31 36 20
20 20 20 20 31 34 30 33 32 30 20 20 68 FA 03 07
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

==

Same result is done also when netmap is not involved; script will take ix0 down
too

# ifconfig  ix0
ix0: flags=8843 metric 0 mtu 1500
   
options=e407b9
ether a0:36:9f:3e:57:18
hwaddr a0:36:9f:3e:57:18
nd6 options=29
media: Ethernet autoselect
status: no carrier


FYI, we do temporary downgrade of driver to 3.1.13-k where issue is not
present.

If I can help with any additional testing, let me know.

Best Regards,
Peter

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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: i386 with 4GB RAM: less than 2GB available on A2SAV (Intel Atom E3940)

[Boris Samorodov]

30.01.2018 09:59, Andre Albsmeier пишет:

> After a BIOS upgrade,

Did you try to reset BIOS to default settings? A BIOS upgrade
is the right time to try this.

> I found the promising option
> 
> MAX TOLUD
> 
> which was set to 2GB. I changed it to 3GB but nothing changed.

Hm, TOLUD is Top Of Lower Usable Dram. That memory is often used
for GPU (minering). I'd say that you may be interested in *decreasing*
it as it is effectively memory that is not used by an OS. There may be
an AUTO choice to try as well.

-- 
WBR, Boris Samorodov (bsam)
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
___
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: i386 with 4GB RAM: less than 2GB available on A2SAV (Intel Atom E3940)

[Eugene Grosbein]

On 30.01.2018 13:59, Andre Albsmeier wrote:

>> Also, I'd like to know reasons that made you stick to 32 bit OS
>> as we have pretty good support for 32 bit applications running under 64 bit 
>> system.
> 
> I (still) have 32 bit machines and don't want to maintain 2 userlands.
> Each machine has its own kernel but userland (updated via nfs) must
> remain 32 bit.
> 
> Or is it possible to boot a 64 bit kernel and have everything else in
> 32 bit?

I have not tried "everything else in 32 bit", there may be some rough edges
dealing with run-time linker but you can try.

/sbin/init is statically linked and it should work with kernel having option 
COMPAT_FREEBSD32.
/bin/sh may be OK too provided /libexec/ld-elf32.so.1 is in place.

You should really consider switching to 64 bit kernel for such hardware.


___
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"