Date: Tue, 30 Jan 2018 16:58:59 -0800 (PST) From: Don Lewis <truckman@FreeBSD.org> To: Mike Tancsa <mike@sentex.net> Cc: Nimrod Levy <nimrodl@gmail.com>, 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: <tkrat.4de600092e3f8d8d@FreeBSD.org> In-Reply-To: <ed1dd16e-0121-a578-23f0-1b3503d6475d@sentex.net> References: <8e842dec-ade7-37d1-6bd8-856ea1a827ca@sentex.net> <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> <CAMgUhppdkcqYTpZEZJ1ScTevPOEK6WRXpg_WP-L-R6rKNhpYAA@mail.gmail.com> <ed1dd16e-0121-a578-23f0-1b3503d6475d@sentex.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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 >> <http://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?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?tkrat.4de600092e3f8d8d>