On 2/12/2018 4:49 PM, Don Lewis wrote:
> On 31 Jan, Eugene Grosbein wrote:
>> 31.01.2018 4:36, 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
>> That's really strange. Could you try to do "sysctl 
>> kern.eventtimer.periodic=1"
>> and re-do the test without extra load?
> I'm having really good luck with the kernel patch attached to this
> message:
> https://docs.freebsd.org/cgi/getmsg.cgi?fetch=417183+0+archive/2018/freebsd-hackers/20180211.freebsd-hackers
> Since applying that patch, I did three poudriere runs to build the set
> of ~1700 ports that I use.  Other than one gmake-related build runaway
> that I've also seen on my AMD FX-8320E, I didn't see any random port
> build failures.  When I was last did some testing a few weeks ago,
> lang/go would almost always fail.  I also would seem random build
> failures in lang/guile or finance/gnucash (which uses guile during its
> build) on both my Ryzen and FX-8320E machines, but those built cleanly
> all three times.
> I even built samba 16 times in a row without a hang.

Cool!  I will give it a try!

In other news, the latest BIOS patch from ASUS for my motherboard
*seems* to have fixed the random hangs.  In the BIOS, I had to dial down
the memory one notch, disable q-states and disable core boost for my non
X Ryzen CPUs.  I did that Friday, and running a load that would
typically lock up the box, survived the weekend.  Same with the box I
have in Zoo.  No random freeze ups.

I was also able to take the amdtemp and amdsmn code from HEAD and
compile it on STABLE to confirm the CPU is / was not overheating.  Peak
temp in the low 50s even with the CPU cores are all maxed out.


Mike Tancsa, tel +1 519 651 3400 x203
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada
freebsd-stable@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Reply via email to