After ino64 update: devel/libunwind failure: cannot preempt symbol '_Ux86_64_local_addr_space' defined
After updating several boxes running CURRENT after introduction of ino64, I have one box which persitently rejects compiling and installing devel/libunwind, as you can finde below. The box in question is running FreeBSD 12.0-CURRENT #22 r319083: Sun May 28 21:18:52 CEST 2017 amd64, WITH_LLD_IS_LD=yes set. Another system, which has also been update to meet ino64, but hasn't completely switch over all ports to the new ABI by recompiling, seems to work. The OS version in question is FreeBSD 12.0-CURRENT #1 r319088: Mon May 29 06:56:45 CEST 2017 amd64, also WITH_LLD_IS_LD=yes set. I tried to recompile again all required ports for devel/libunwind via portmaster -f, even some addtional ports on a hunch like gmake, gperf etc., but without any success. The difference on both hosts is the CPU: the failing is IvyBridge XEON, the working one is a Haswell XEON. I'm out of ideas :-( If someone has some ideas, please send me an email. thanks, Oliver [...] libtool: link: cc -O2 -pipe -O3 -fstack-protector -fno-strict-aliasing -fexceptions -Wall -Wsign-compare -fstack-protector -o .libs/Gperf-trace Gperf-trace.o ../src/.libs/libunwind-x86_64.so /usr/ports/devel/libunwind/work/libunwind-1.2/src/.libs/libunwind.so ../src/.libs/libunwind.so -lgcc_s -llzma -Wl,-rpath -Wl,/usr/local/lib --- Gperf-simple --- /usr/bin/ld: error: Gperf-simple.c:(function main): cannot preempt symbol '_Ux86_64_init_local' defined in ../src/.libs/libunwind-x86_64.so /usr/bin/ld: error: Gperf-simple.c:(function main): cannot preempt symbol '_Ux86_64_init_local' defined in ../src/.libs/libunwind-x86_64.so /usr/bin/ld: error: Gperf-simple.c:(function main): cannot preempt symbol '_Ux86_64_local_addr_space' defined in ../src/.libs/libunwind-x86_64.so /usr/bin/ld: error: Gperf-simple.c:(function main): cannot preempt symbol '_Ux86_64_set_caching_policy' defined in ../src/.libs/libunwind-x86_64.so /usr/bin/ld: error: Gperf-simple.c:(function main): cannot preempt symbol '_Ux86_64_local_addr_space' defined in ../src/.libs/libunwind-x86_64.so /usr/bin/ld: error: Gperf-simple.c:(function main): cannot preempt symbol '_Ux86_64_set_caching_policy' defined in ../src/.libs/libunwind-x86_64.so /usr/bin/ld: error: Gperf-simple.c:(function main): cannot preempt symbol '_Ux86_64_local_addr_space' defined in ../src/.libs/libunwind-x86_64.so /usr/bin/ld: error: Gperf-simple.c:(function main): cannot preempt symbol '_Ux86_64_set_caching_policy' defined in ../src/.libs/libunwind-x86_64.so /usr/bin/ld: error: Gperf-simple.c:(function measure_unwind): cannot preempt symbol '_Ux86_64_init_local' defined in ../src/.libs/libunwind-x86_64.so /usr/bin/ld: error: Gperf-simple.c:(function measure_unwind): cannot preempt symbol '_Ux86_64_step' defined in ../src/.libs/libunwind-x86_64.so --- Gperf-trace --- /usr/bin/ld: error: Gperf-trace.c:(function main): cannot preempt symbol '_Ux86_64_init_local' defined in ../src/.libs/libunwind-x86_64.so /usr/bin/ld: error: Gperf-trace.c:(function main): cannot preempt symbol '_Ux86_64_init_local' defined in ../src/.libs/libunwind-x86_64.so /usr/bin/ld: error: Gperf-trace.c:(function main): cannot preempt symbol '_Ux86_64_local_addr_space' defined in ../src/.libs/libunwind-x86_64.so /usr/bin/ld: error: Gperf-trace.c:(function main): cannot preempt symbol '_Ux86_64_set_caching_policy' defined in ../src/.libs/libunwind-x86_64.so /usr/bin/ld: error: Gperf-trace.c:(function main): cannot preempt symbol '_Ux86_64_local_addr_space' defined in ../src/.libs/libunwind-x86_64.so /usr/bin/ld: error: Gperf-trace.c:(function main): cannot preempt symbol '_Ux86_64_set_caching_policy' defined in ../src/.libs/libunwind-x86_64.so /usr/bin/ld: error: Gperf-trace.c:(function main): cannot preempt symbol '_Ux86_64_local_addr_space' defined in ../src/.libs/libunwind-x86_64.so /usr/bin/ld: error: Gperf-trace.c:(function main): cannot preempt symbol '_Ux86_64_set_caching_policy' defined in ../src/.libs/libunwind-x86_64.so --- Gperf-simple --- cc: error: linker command failed with exit code 1 (use -v to see invocation) --- Gperf-trace --- cc: error: linker command failed with exit code 1 (use -v to see invocation) *** [Gperf-trace] Error code 1 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: NFS client perf. degradation when SCHED_ULE is used (was when SMP enabled)
On 28/05/2017 01:20, Rick Macklem wrote: > - with the "obvious change" mentioned in r312426's commit message, using >(flags & SW_TYPE_MASK) == SWT_RELINQUISH instead of (flag & SWT_RELINQUISH) >121minutes Rick, can I see how exactly your variant of the obvious change looks in your version? I am asking, because I meant applying that change to the original code while it can be also interpreted as applying it to the code after r312426. That is, does it looks like this: preempted = !((td->td_flags & TDF_SLICEEND) || ((flags & SW_TYPE_MASK) == SWT_RELINQUISH)); or like this: preempted = !(td->td_flags & TDF_SLICEEND) && ((flags & SW_TYPE_MASK) == SWT_RELINQUISH); > I also tested: > ((flags & SW_PREEMPT) != 0 || (flags & SW_TYPE_MASK) == SWT_IDLE || > (flags & SW_TYPE_MASK) == SWT_IWAIT) > and it also resulted in121minutes So, this sets the preempted flag for SWT_IDLE and SWT_IWAIT cases. The flag makes any difference only if the current thread is calling mi_switch() but remains running (of which typical cases are preemption and yielding). As far as I can tell, mi_switch(SWT_IWAIT) is only called when the thread is already inhibited via TD_SET_IWAIT, so that should not make any difference. SWT_IDLE is set only when the current thread is an idle thread, so that should not make any difference either. Thus, I am puzzled as to why this change could make any difference. Could you please post full code snippets for each local change that you tried? Also, could you please capture KTR sched trace while running the test on the kernel with no local modifications and on the 1yr old kernel? Ideally, I would like to see the trace with KTR_SCHED | KTR_RUNQ compiled into the kernel via KTR_COMPILE and then enabled at the run time via debug.ktr.mask=0x2040. Thank you. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
ino64 status update and upgrade caution
The ino64 project was committed to src last week[1][2] with UPDATING notes added shortly thereafter [3][4][5]. As some people have been tripped up by the ino64 change I want to emphasize again that the upgrade procedure described in UPDATING should be followed exactly. The reboot after installing the new ino64 kernel, and the addition of COMPAT_FREEBSD11 to custom kernel configurations, are crucial steps. Note that this upgrade is just the usual standard, documented procedure and is required whenever new syscalls or other forwards-incompatible changes are introduced. Prior to ino64 we have had a period without any significant Application Binary Interface (ABI) or Kernel Binary Interface (KBI) changes and it was possible to take shortcuts with the upgrade procedure. The ino64 change is backwards-compatible but not forwards-compatible and shortcuts must not be taken. (As a general rule, it is safest to always use the full procedure unless you follow the commit mailing list and are aware of which changes are not foward-compatible.) In addition, some users have created a libarchive.so.6 symlink to libarchive.so.7, in an attempt to run older binaries on a fresh post- ino64 install. Do not do this: libarchive.so.6 and libarchive.so.7 have an incompatible ABI and this will result in incorrect and unpredictable behaviour. The most recent -CURRENT package set was built prior to the ino64 commit, and thus will not work on a fresh ino64 install or snapshot image. Until the next package set is available please build from ports, or use Poudriere to build your own package set. Most ports with a dependency on ino64 have now been patched. The remaining ports which still need a change for ino64 are: PortResponsible for # Skipped -- lang/gcc6-aux 54 sysutils/py-psutil13 (fix in review D10801) devel/llvm38 6 sysutils/py-psutil121 3 devel/radare2 0 emulators/qemu-user-static 0 lang/ccl 0 lang/dmd2 0 lang/gcc5-aux 0 lang/modula3 0 lang/rust-nightly 0 lang/twelf 0 lang/urweb 0 net-mgmt/netdata 0 [1] https://svnweb.freebsd.org/changeset/base/318736 [2] https://svnweb.freebsd.org/changeset/base/318737 [3] https://svnweb.freebsd.org/changeset/base/318757 [4] https://svnweb.freebsd.org/changeset/base/318758 [5] https://svnweb.freebsd.org/changeset/base/318792 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: After ino64 update: devel/libunwind failure: cannot preempt symbol '_Ux86_64_local_addr_space' defined
On 29 May 2017 at 04:59, O. Hartmann wrote: > After updating several boxes running CURRENT after introduction of ino64, I > have one box which persitently rejects compiling and installing > devel/libunwind, as you can finde below. > > The box in question is running FreeBSD 12.0-CURRENT #22 r319083: Sun May 28 > 21:18:52 CEST 2017 amd64, WITH_LLD_IS_LD=yes set. What's the difference between this and the report in PR 219524? AFAICT this is just a known issue with the libunwind port and LLD, and will need a change in libunwind to fix. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Xorg error 'alphasort'
First try, did not build, to try to fix, Xorg, took the easy way out and restored the /usr/local/bin/Xorg that was working two days ago from backup. Xorg.log.0 says it is devd??? ... error in Subject is only from memory. ... Fixed, temporarily, in under 15 minutes here. No time to investigate further, just wondering... . 1.18.4,1 >> 1.18.4_1,1 xorg-server was done within the last 12 hours from pkg 12.0-CURRENT ino64? not upto speed... on that either. Not tested: xorg-vfbserver xorg-nestserver ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
side-effects from mesa-libs and ino64 updates ...?
I would appreciate observations about two difficulties that have surfaced for me since the mesa-libs and ino64 updates. Likely these are pilot errors but I've not been able to identify the causes. Here's the environment ... FreeBSD silver 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r318232: Fri May 12 00:21:37 PDT 2017 root@silver:/usr/src/sys/amd64/compile/silver amd64 /usr/src revision: 319159 /etc/src-env.conf WITH_META_MODE=yes NO_SILENT=yes rm -r /usr/obj 1. buildworld runs now fail: Building /usr/obj/usr/src/share/colldef/es_MX.UTF-8.LC_COLLATE --- all_subdir_lib --- /usr/obj/usr/src/tmp/usr/lib/libgcc_s.so: undefined reference to `__gxx_personality_v0' cc: error: linker command failed with exit code 1 (use -v to see invocation) 2. with ports as of: Fetching snapshot metadata... done. Updating from Sat May 27 09:42:54 PDT 2017 to Sun May 28 16:37:47 PDT 2017. echo $QT_SELECT qt5 attempting to re-install devel/py-qt5-core with portmaster -d py27-qt5-core yields Error: Failed to determine the detail of your Qt installation. Thanks for your thoughts. Kevin Casey ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
