Date: Tue, 30 Jan 2018 22:23:52 +0000 From: Nimrod Levy <nimrodl@gmail.com> To: Mike Tancsa <mike@sentex.net> Cc: Don Lewis <truckman@freebsd.org>, freebsd-stable@freebsd.org, Peter Moody <freebsd@hda3.com>, Andriy Gapon <avg@freebsd.org>, Pete French <petefrench@ingresso.co.uk> Subject: Re: Ryzen issues on FreeBSD ? (with sort of workaround) Message-ID: <CAMgUhppdkcqYTpZEZJ1ScTevPOEK6WRXpg_WP-L-R6rKNhpYAA@mail.gmail.com> In-Reply-To: <c0319297-d47d-449d-a6f1-2529d1d38541@sentex.net> References: <8e842dec-ade7-37d1-6bd8-856ea1a827ca@sentex.net> <dd29d77a-deb9-423e-f9b8-cb07387bbfd5@sentex.net> <9b769e4e-b098-b294-0bce-8bb1c42e8a59@rootautomation.com> <a601973f-9205-8dd9-7f78-a7f03985ab4a@sentex.net> <CAMgUhpop3=J7TQimK2iHdGTc=hnTgCEZDqibDSRCyTPMWX5wJQ@mail.gmail.com> <CAMgUhpop54hJ%2Biq_VYYqrEHgSapmMu_GmOPaOsmhA=QbjPEZ5A@mail.gmail.com> <CADbMJxk=HDoMsPghDrkTNqsC_XZo28nYPNGC%2BD9fddENPiiFng@mail.gmail.com> <730eb882-1c6a-afb7-0ada-396db44fb34b@ingresso.co.uk> <tkrat.8fa97919286143d7@FreeBSD.org> <8b882970-4d5d-2a96-4dac-779cab07b9ae@sentex.net> <CADbMJxkRR8s1=WWXP%2BH9eOHv_UWMQrUR=_E4aFw91VCeep82pw@mail.gmail.com> <343acf99-3e9e-093a-7390-c142396c2985@sentex.net> <tkrat.975666e9f483a6a0@FreeBSD.org> <3dd9a61b-511d-db2e-80ca-cbc9a4b65f92@sentex.net> <tkrat.ada77e0420783bed@FreeBSD.org> <55913e41-3a8a-9a4d-6862-e09a3d0f4d55@sentex.net> <tkrat.e541d1b83f4f6c75@FreeBSD.org> <5e48bbc2-e872-46bd-eece-25acbb180f77@sentex.net> <c0319297-d47d-449d-a6f1-2529d1d38541@sentex.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <mike@sentex.net> 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 > > PID TID COMM TDNAME 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 > > PID TID COMM TDNAME 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 > > hw.lower_amd64_sharedpage: 1 > > post reboot, > > > > CTRL+T shows > > load: 2.73 cmd: python2.7 15703 [usem] 40.92r 12.34u 3.45s 0% 233640k > > make[1]: Working in: /usr/ports/net/samba47 > > make: Working in: /usr/ports/net/samba47 > > > > > > > > root@amdtestr12:/home/mdtancsa # procstat -kk 15703 > > PID TID COMM TDNAME KSTACK > > > > 15703 100824 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 > > 15703 100956 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 > > 15703 100957 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 > > 15703 100958 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 > > 15703 100959 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 > > 15703 100960 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 > > 15703 100961 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 > > 15703 100962 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 > > 15703 100963 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 > > 15703 100964 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 > > 15703 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 > > 15703 100966 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 > > 15703 100967 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 > > root@amdtestr12:/home/mdtancsa # procstat -t 15703 > > PID TID COMM TDNAME CPU PRI STATE > > WCHAN > > 15703 100824 python2.7 - -1 152 sleep > > usem > > 15703 100956 python2.7 - -1 125 sleep > > usem > > 15703 100957 python2.7 - -1 127 sleep > > usem > > 15703 100958 python2.7 - -1 125 sleep > > usem > > 15703 100959 python2.7 - -1 125 sleep > > usem > > 15703 100960 python2.7 - -1 126 sleep > > usem > > 15703 100961 python2.7 - -1 126 sleep > > usem > > 15703 100962 python2.7 - -1 126 sleep > > usem > > 15703 100963 python2.7 - -1 126 sleep > > usem > > 15703 100964 python2.7 - -1 126 sleep > > usem > > 15703 100965 python2.7 - -1 126 sleep > > umtxn > > 15703 100966 python2.7 - -1 126 sleep > > usem > > 15703 100967 python2.7 - -1 125 sleep > > usem > > root@amdtestr12:/home/mdtancsa # > > > > > > ---Mike > > > > > >> > >> ------------------------------------------------------------------------ > >> r321608 | kib | 2017-07-27 01:37:07 -0700 (Thu, 27 Jul 2017) | 9 lines > >> > >> Use MFENCE to serialize RDTSC on non-Intel CPUs. > >> > >> Kernel already used the stronger barrier instruction for AMDs, correct > >> the userspace fast gettimeofday() implementation as well. > >> > >> > >> > >> I did go back and look at the build runaways that I've occasionally seen > >> on my AMD FX-8320E package builder. I haven't seen the python issue > >> there, but have seen gmake get stuck in a sleeping state with a bunch of > >> zombie offspring. > >> > >> > > > > > > > -- > ------------------- > Mike Tancsa, tel +1 519 651 3400 <(519)%20651-3400> > Sentex Communications, mike@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-unsubscribe@freebsd.org" > -- -- Nimrod
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAMgUhppdkcqYTpZEZJ1ScTevPOEK6WRXpg_WP-L-R6rKNhpYAA>