Re: Heads up: OFED build by default
OFED in head lead to the following in order for ci.freebsd.org's FreeBSD-head-amd64-gcc builds to not fail/stop in all_subdir_lib/ofed : Author: jhb Date: Mon Aug 6 23:51:08 2018 New Revision: 337399 URL: https://svnweb.freebsd.org/changeset/base/337399 Log: Make the system C11 atomics headers fully compatible with external GCC. The and headers already included support for C11 atomics via intrinsincs in modern versions of GCC, but these versions tried to "hide" atomic variables inside a wrapper structure. This wrapper is not compatible with GCC's internal header, so that if GCC's was used together with , use of C11 atomics would fail to compile. Fix this by not hiding atomic variables in a structure for modern versions of GCC. The headers already avoid using a wrapper structure on clang. Note that this wrapper was only used if C11 was not enabled (e.g. via -std=c99), so this also fixes compile failures if a modern version of GCC was used with -std=c11 but with FreeBSD's instead of GCC's and this change fixes that case as well. Reported by: Mark Millard Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D16585 Modified: head/sys/sys/cdefs.h head/sys/sys/stdatomic.h Without this FreeBSD-head-amd64-gcc was getting: --- all_subdir_lib/ofed --- In file included from /workspace/src/contrib/ofed/librdmacm/cma.h:43:0, from /workspace/src/contrib/ofed/librdmacm/acm.c:42: /workspace/src/contrib/ofed/librdmacm/cma.h: In function 'fastlock_init': /workspace/src/contrib/ofed/librdmacm/cma.h:60:2: error: invalid initializer atomic_store(&lock->cnt, 0); ^ In file included from /workspace/src/contrib/ofed/librdmacm/acm.c:42:0: /workspace/src/contrib/ofed/librdmacm/cma.h: In function 'fastlock_acquire': /workspace/src/contrib/ofed/librdmacm/cma.h:68:2: error: operand type 'struct *' is incompatible with argument 1 of '__atomic_fetch_add' if (atomic_fetch_add(&lock->cnt, 1) > 0) ^~ /workspace/src/contrib/ofed/librdmacm/cma.h: In function 'fastlock_release': /workspace/src/contrib/ofed/librdmacm/cma.h:73:2: error: operand type 'struct *' is incompatible with argument 1 of '__atomic_fetch_sub' if (atomic_fetch_sub(&lock->cnt, 1) > 1) ^~ . . . --- all_subdir_lib/ofed --- *** [acm.o] Error code 1 Side notes: A modern enough /usr/ports avoids the devel/*-gcc the separate float.h problem: -r476273 fixed /devel/powerpc64-gcc (the master port for devel/*-gcc ports) to avoid this. With both fixes in place I was able to buildworld buildkernel via amd64's xtoolchain ( so via its use of devel/amd64-gcc ). (The build servers likely do not have -r476273 yet.) === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ 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: How do I stop using local_unbound ?
On Tue, 2018-08-07 at 15:35 +0100, Pete French wrote: > > > > Hmm. First, make sure that it isn't running (service local_unbound > > stop, etc). > > Then look at your /etc/resolv.conf -- unbound tends to rewrite that > > on initial > > startup, taking some of it's settings and inserting itself into the > > middle as a > > caching DNS server. At the very least, you want something like this: > > > > nameserver 8.8.8.8 > > > > I think the default DHCP client stomps all over /etc/resolv.conf > > fairly well, > Thats my problem - it doesnt rewrite it :-( I ended up taking one of my > machines with a working unboudn setup, rysncing the files to the non > working ones, re-enabling unbound and lettign it get on with its life. > Have given up on removing it! > > Thanks for the advice though, I will dig into it on more detail when I > have a moment. > > cheers, > > -pete. I wonder if OpenResolve is involved in rewriting the config. Do you have an /etc/resolvconf.conf file, and if so, does it contain configuration related to updating unbound? -- Ian ___ 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: How do I stop using local_unbound ?
Hmm. First, make sure that it isn't running (service local_unbound stop, etc). Then look at your /etc/resolv.conf -- unbound tends to rewrite that on initial startup, taking some of it's settings and inserting itself into the middle as a caching DNS server. At the very least, you want something like this: nameserver 8.8.8.8 I think the default DHCP client stomps all over /etc/resolv.conf fairly well, Thats my problem - it doesnt rewrite it :-( I ended up taking one of my machines with a working unboudn setup, rysncing the files to the non working ones, re-enabling unbound and lettign it get on with its life. Have given up on removing it! Thanks for the advice though, I will dig into it on more detail when I have a moment. cheers, -pete. ___ 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: All the memory eaten away by ZFS 'solaris' malloc - on 11.1-R amd64
On Sat, Aug 04, 2018 at 08:38:04PM +0200, Mark Martinec wrote:
2018-08-04 19:01, Mark Johnston wrote:
> I think running "zpool list" is adding a lot of noise to the output.
> Could you retry without doing that?
No, like I said previously, the "zpool list" (with one defunct
zfs pool) *is* the sole culprit of the zfs memory leak.
With each invocation of "zpool list" the "solaris" malloc
jumps up by the same amount, and never ever drops. Without
running it (like repeatedly under 'telegraf' monitoring
of zfs), the machine runs normally and never runs out of
memory, the "solaris" malloc count no longer grows steadily.
2018-08-04 21:47, Mark Johnston wrote:
Sorry, I missed that message. Given that information, it would be
useful to see the output of the following script instead:
# dtrace -c "zpool list -Hp" -x temporal=off -n '
dtmalloc::solaris:malloc
/pid == $target/{@allocs[stack(), args[3]] = count()}
dtmalloc::solaris:free
/pid == $target/{@frees[stack(), args[3]] = count();}'
This will record all allocations and frees from a single instance of
"zpool list".
Collected, here it is:
https://www.ijs.si/usr/mark/tmp/dtrace-cmd.out.bz2
Kevin P. Neal wrote:
Was there a mention of a defunct pool?
Indeed.
Haven't tried yet to destroy it, so it is only my hypothesis
that a defunct pool plays a role in this leak.
I've got a machine with 8GB RAM running 11.1-RELEASE-p4 with a single
ZFS
pool. It runs zfs list in a script multiple times a minute, and it has
been doing so for 181 days with no reboot. I have not seen any memory
issues.
I have jumped from 10.3 directly to 11.1-RELEASE-p11, so I'm not sure
with exactly which version / patch level the problem was introduced.
Tried to reproduce the problem on another host running 11.2R,
using memory disk (md), created GPT partition on it and a ZFS pool
on top, then destroyed the disk, so the pool was left as UNAVAILABLE.
Unfortunately this did not reproduce the problem, the "zpool list"
on that host does not cause ZFS to leak memory. Must be something
specific to that failed disk or pool, which is causing the leak.
Mark
___
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"
Heads up: OFED build by default
I am going to merge revisions r336568, r336569, and r336570 from HEAD to stable/11. They enable the build of the OFED libraries by default, and move the build of most of the utilities under the WITH_OFED_EXTRA knob. Also as a minor fix, since libpcap lives in /lib and depends on two OFED libraries, these libraries are moved into /lib. I do not expect that any user of stable/11 would be seriosly affected by the change. Small detail is that / filesystem becomes somewhat larger. Slightly bigger detail is that if you really need OpenSM or some of the utilities, you should use WITH_OFED_EXTRA instead of WITH_OFED knob. ___ 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"
