powerpc64 10.1-STABLE context; cmake's /usr/local/bin/ctest broken but graphics/png configuration defaults use it
Mark Millard
markmi at dsl-only.net
Mon Mar 9 01:35:11 UTC 2015
Thanks for the note. It is useful to know the variation from my context.
You were not explicit but because you mention POWER8 I'd guess that you were reporting based on 11.0-CURRENT. I have not yet established an 11.0-CURRENT boot-context, although I plan to at some point.
powerpc64 vs. powerpc builds give different results...
For powerpc64 I decided to "pkg delete '*'", check /usr/local/... and /var/db/pkg/..., and start a rebuild of all my ports to see what happens. For powerpc I'm just establishing a boot-SSD context now.
The activity for both has gotten past cmake and I get the following results for ctest on the G5s where the builds are running:
powerpc64 build: ctest still messed up with std::length_error from vector::reserve.
powerpc build: ctest works fine.
Both are being run on PowerMac G5s. Both are still building more ports.
As for potential HW problems and HW configuration problems:
I have access to 3 PowerMac G5's and they all behaved the same for each specific build:
PowerMac11,2 (Quad-Core) G5 with 16GBytes ECC RAM
PowerMac11,2 (Quad-Core) G5 with 12GBytes RAM
PowerMac7,2 (Dual-processor) G5 with 8GBytes RAM
All of these have only one board installed: the video board. Normally there is only one "disk" present when in use: a boot SSD on ada0.
The only common HW element in my testing G5 behavior is my moving my boot SSD that I'm testing.
Non-SSD hardware is rarely the issue with anything that I report unless I'm reporting differences in behavior between the PowerMacs that I have access to for the type of build involved: I have a compare/contrast environment available for my testing and I use it.
[I have access to multiple G4 PowerMacs of various vintages and a G3 PowerMac as well, similarly minimal configurations. But I'm only now re-establishing having a FreeBSD context for these after mostly abandoning them for much of the 9-10 months while I was investigating the frequent PowerMac G5 early-boot-crash problems as my primary FreeBSD activity.]
The powerpc64 PowerMac G5 boot-SSD content that I use for 10.1-STABLE and 10.1-RELENG could certainly be suspect in some way. :) I mostly use 10.1-STABLE, currently:
$ freebsd-version -ku; uname -a
10.1-STABLE
10.1-STABLE
FreeBSD FBSDG5S0 10.1-STABLE FreeBSD 10.1-STABLE #0 r279507M: Fri Mar 6 23:08:59 PST 2015 root at FBSDG5S0:/usr/obj/usr/src/sys/GENERIC64vtsc powerpc
As for other configuration points:
See my original note for more details on the difference from the official world/kernel materials. There is also /boot/loader.conf picking out a kernel (I use INSTKERNNAME= with non-default names mostly) and picking out vt vs. sc, /etc/fstab, /etc/rc.conf (hostname, ifconfig_<?> for ethernet, ntpd_<?>, dumpdev, hald_enable, dbus_enable), /etc/sysctl.conf for /var/crash/ related items. Counting the original note's list of differences: Not much else is different from the default/official materials.
For ports configurations: Before I had suspended trying to track the ports status I historically had used almost every default selection, something like 2 to 6 non-default selections. (I keep a snapshot of /var/db/ports/... as a reference/reminder.) I've got the same policy for trying to re-establish the ports now that I can reliably boot the G5s.
===
Mark Millard
markmi at dsl-only.net
On 2015-Mar-8, at 09:49 AM, Nathan Whitehorn <nwhitehorn at freebsd.org> wrote:
This works fine for me. Are you sure you don't have some weird configuration or hardware problem?
-Nathan
On 03/07/15 22:56, Mark Millard wrote:
> powerpc64 context (more details are listed much later):
>
> $ freebsd-version -ku; uname -a
> 10.1-STABLE
> 10.1-STABLE
> FreeBSD FBSDG5S0 10.1-STABLE FreeBSD 10.1-STABLE #0 r279507M: Fri Mar 6 23:08:59 PST 2015 root at FBSDG5S0:/usr/obj/usr/src/sys/GENERIC64vtsc powerpc
>
> Ports Revision 380683 via svnlite update. I've been using portmaster.
>
>
> The problem (which I've not figured out yet)...
>
> When png-1.6.16 has PNGTEST enabled (default and "recommended") it tries to use cmake's /usr/local/bin/ctest. But in my context ctest is broken, trying to reserve 2305843009213693952 Hashtable_node<...>*'s [see #8's ...::reserve (..., __n=...) below] when _M_initialize_buckets(..., __n=100) in #9. (Note: 2305843009213693952 == 0x2000000000000000.) I have yet to figure out how that magic number is becoming involved. See below from one of the crash dumps:
>
> #0 0x0000000050d17298 in .__sys_thr_kill () from /lib/libc.so.7
> [New Thread 51c06400 (LWP 100091/ctest)]
> (gdb) bt
> #0 0x0000000050d17298 in .__sys_thr_kill () from /lib/libc.so.7
> #1 0x0000000050d171ac in .__raise () from /lib/libc.so.7
> #2 0x0000000050d15788 in .abort () from /lib/libc.so.7
> #3 0x00000000514c9ae0 in ._ZN9__gnu_cxx27__verbose_terminate_handlerEv () from /usr/lib/libsupc++.so.1
> #4 0x00000000514cf1d8 in ._ZSt14set_unexpectedPFvvE () from /usr/lib/libsupc++.so.1
> #5 0x00000000514cf230 in ._ZSt9terminatev () from /usr/lib/libsupc++.so.1
> #6 0x00000000514cf0dc in .__cxa_throw () from /usr/lib/libsupc++.so.1
> #7 0x0000000050ab4e54 in ._ZSt20__throw_length_errorPKc () from /usr/lib/libstdc++.so.6
> #8 0x000000001024659c in std::vector<cmsys::_Hashtable_node<std::pair<std::string const, cmDefinitions::Def> >*, std::allocator<cmsys::_Hashtable_node<std::pair<std::string const, cmDefinitions::Def> >*> >::reserve (this=0xffffffffffffb108, __n=2305843009213693952) at vector.tcc:72
> #9 0x00000000104749bc in cmsys::hashtable<std::pair<std::string const, cmDefinitions::Def>, std::string, cmsys::hash<std::string>, cmsys::hash_select1st<std::string const, cmDefinitions::Def>, std::equal_to<std::string>, std::allocator<char> >::_M_initialize_buckets (this=0xffffffffffffb100, __n=100) at hashtable.hxx:797
> #10 0x0000000010474ae4 in hashtable (this=0xffffffffffffb100, __n=100, __hf=@0xffffffffffffaeb2, __eql=@0xffffffffffffaeb1, __a=@0xffffffffffffaeb0) at hashtable.hxx:545
> #11 0x0000000010474bb8 in hash_map (this=0xffffffffffffb100) at hash_map.hxx:113
> #12 0x0000000010472ba4 in cmDefinitions (this=0xffffffffffffb0f8, parent=0x0) at /usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.3/Source/cmDefinitions.cxx:19
> #13 0x000000001020dc40 in cmMakefile (this=0x51cb1800) at /usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.3/Source/cmMakefile.cxx:56
> #14 0x00000000101efb0c in cmLocalGenerator::SetGlobalGenerator (this=0x51c3f480, gg=0xffffffffffffc138) at /usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.3/Source/cmLocalGenerator.cxx:244
> #15 0x00000000101874b0 in cmGlobalGenerator::CreateLocalGenerator (this=0xffffffffffffc138) at /usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.3/Source/cmGlobalGenerator.cxx:1906
> #16 0x00000000100224dc in cmCTest::Initialize (this=0xffffffffffffcf50, binary_dir=0x51c890f8 "/usr/obj/portswork/usr/ports/graphics/png/work/libpng-1.6.16", command=0x0)
> at /usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.3/Source/cmCTest.cxx:511
> #17 0x000000001002c704 in cmCTest::Run (this=0xffffffffffffcf50, args=@0xffffffffffffcb80, output=0xffffffffffffcb98) at /usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.3/Source/cmCTest.cxx:2474
> #18 0x0000000010010c10 in main (argc=2, argv=0x51c1a040) at /usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.3/Source/ctest.cxx:189
> #19 0x000000001000fc9c in ._start ()
> #20 0x000000005074c8a0 in .text () from /libexec/ld-elf.so.1
>
> The specific Makefile code to invoke ctest is...
>
> # Special rule for the target test
> test:
> @$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR) --cyan "Running tests..."
> /usr/local/bin/ctest --force-new-ctest-process $(ARGS)
> .PHONY : test
> # Special rule for the target test
> test/fast: test
> .PHONY : test/fast
>
> which because of ctest's problem leads to...
>
> ...
> Linking C executable pngvalid
> [100%] Built target pngvalid
> (cd /usr/obj/portswork/usr/ports/graphics/png/work/libpng-1.6.16; if ! /usr/bin/env XDG_DATA_HOME=/usr/obj/portswork/usr/ports/graphics/png/work XDG_CONFIG_HOME=/usr/obj/portswork/usr/ports/graphics/png/work HOME=/usr/obj/portswork/usr/ports/graphics/png/work TMPDIR="/tmp" XDG_DATA_HOME=/usr/obj/portswork/usr/ports/graphics/png/work XDG_CONFIG_HOME=/usr/obj/portswork/usr/ports/graphics/png/work HOME=/usr/obj/portswork/usr/ports/graphics/png/work TMPDIR="/tmp" DONTSTRIP=yes NO_PIE=yes SHELL=/bin/sh NO_LINT=YES PREFIX=/usr/local LOCALBASE=/usr/local LIBDIR="/usr/lib" CC="cc" CFLAGS="-pipe -g -fno-strict-aliasing" CPP="cpp" CPPFLAGS="" LDFLAGS="" LIBS="" CXX="c++" CXXFLAGS="-pipe -g -fno-strict-aliasing " MANPREFIX="/usr/local" BSD_INSTALL_PROGRAM="install -o root -g wheel -m 555" BSD_INSTALL_LIB="install -o root -g wheel -m 444" BSD_INSTALL_SCRIPT="install -o root -g wheel -m 555" BSD_INSTALL_DATA="install -o root -g wheel -m 0644" BSD_INSTALL_MAN="instal!
> l -o roo
> t -g wheel -m 444" /usr/bin/make -f Makefile -j4 DESTDIR=/usr/obj/portswork/usr/ports/graphics/png/work/stage test; then if [ x != xTry to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to the maintainer. ] ; then echo "===> Compilation failed unexpectedly."; (echo Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to the maintainer.) | /usr/bin/fmt 75 79 ; fi; false; fi)
> Running tests...
> terminate called after throwing an instance of 'std::length_error'
> what(): vector::reserve
> Abort trap (core dumped)
> *** [test] Error code 134
>
> make[2]: stopped in /usr/obj/portswork/usr/ports/graphics/png/work/libpng-1.6.16
> 1 error
>
> make[2]: stopped in /usr/obj/portswork/usr/ports/graphics/png/work/libpng-1.6.16
> [: xTry: unexpected operator
> *** Error code 1
>
> Stop.
> make[1]: stopped in /usr/ports/graphics/png
> *** Error code 1
>
> Stop.
> make: stopped in /usr/ports/graphics/png
>
>
> Even just ctest as a command gets the vector::reserve size problem from the large magic number:
>
> $ ctest
> *********************************
> No test configuration file found!
> *********************************
> terminate called after throwing an instance of 'std::length_error'
> what(): vector::reserve
> Abort trap (core dumped)
>
>
> [So far I've only sidestepped having graphic/png run ctest to allow some things that depend on graphics/png to not be blocked by this.]
>
>
>
>
> For my context the overall environment has (but ports might force other ports as alternatives to):
>
> # more /etc/make.conf
> #CPP=clang-cpp
> #CC=clang
> #CXX=clang++
> WRKDIRPREFIX=/usr/obj/portswork
> WITH_DEBUG=
> MALLOC_PRODUCTION=
>
> # more /etc/src.conf
> #CPP=clang-cpp
> #CC=clang
> #CXX=clang++
> #CFLAGS+=-DELF_VERBOSE
> #WITH_DEBUG_FILES=
> #WITHOUT_CLANG=
>
> # which cc
> /usr/bin/cc
>
> # cc --version
> cc (GCC) 4.2.1 20070831 patched [FreeBSD]
> Copyright (C) 2007 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions. There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> # which clang
> /usr/bin/clang
>
> # clang --version
> FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512
> Target: powerpc64-unknown-freebsd10.1
> Thread model: posix
>
>
>
>
>
> Other context details:
>
> $ cd /usr/ports
> $ svnlite info
> Path: .
> Working Copy Root Path: /usr/ports
> URL: https://svn0.us-west.freebsd.org/ports/head
> Relative URL: ^/head
> Repository Root: https://svn0.us-west.freebsd.org/ports
> Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
> Revision: 380683
> Node Kind: directory
> Schedule: normal
> Last Changed Author: demon
> Last Changed Rev: 380683
> Last Changed Date: 2015-03-07 03:31:11 -0800 (Sat, 07 Mar 2015)
>
> $ svnlite st --no-ignore
> ? .snap
> I distfiles
> M graphics/libGL/bsd.mesalib.mk
> I packages
> ? restoresymtable
>
> $ svnlite diff graphics/libGL/bsd.mesalib.mk
> Index: graphics/libGL/bsd.mesalib.mk
> ===================================================================
> --- graphics/libGL/bsd.mesalib.mk (revision 380683)
> +++ graphics/libGL/bsd.mesalib.mk (working copy)
> @@ -136,6 +136,10 @@
> CONFIGURE_ARGS+=--enable-vdpau
> .endif
>
> +.if ${ARCH} == powerpc64
> +CFLAGS+= -mminimal-toc
> +.endif
> +
> post-patch:
> @${REINPLACE_CMD} -e 's|-ffast-math|${FAST_MATH}|' -e 's|x86_64|amd64|' \
> ${WRKSRC}/configure
>
> $ cd /usr/src
> $ svnlite info
> Path: .
> Working Copy Root Path: /usr/src
> URL: https://svn0.us-west.freebsd.org/base/stable/10
> Relative URL: ^/stable/10
> Repository Root: https://svn0.us-west.freebsd.org/base
> Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
> Revision: 279507
> Node Kind: directory
> Schedule: normal
> Last Changed Author: ngie
> Last Changed Rev: 279507
> Last Changed Date: 2015-03-01 14:12:24 -0800 (Sun, 01 Mar 2015)
>
> $ svnlite st --no-ignore
> ? .snap
> ? restoresymtable
> M sys/ddb/db_main.c
> M sys/ddb/db_script.c
> I sys/powerpc/conf/GENERIC64vtsc
> I sys/powerpc/conf/GENERICvtsc
> M sys/powerpc/ofw/ofw_machdep.c
> M sys/powerpc/ofw/ofwcall64.S
> M sys/powerpc/powerpc/dump_machdep.c
>
> sys/powerpc/ofw/ofw_machdep.c has a PowerMac G5 specific change to avoid intermittent boot problems.
>
> sys/ddb/... and sys/powerpc/ofw/ofwcall64.S are just to help me get evidence if I do end up with another early-boot failure. DDB and GDB are listed in sys/powerpc/conf/GENERIC64vtsc for the same reason.
>
> sys/powerpc/powerpc/dump_machdep.c is from me forcing the DMA transfer size for dumps to be small enough not to be rejected as too large of a DMA request size.
>
> sys/powerpc/conf/GENERIC64vtsc turns off ps3 in order to turn on both vt and sc. It includes the standard GENERIC64.
>
> ===
> Mark Millard
> markmi at dsl-only.net
>
> _______________________________________________
> freebsd-ppc at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-ppc
> To unsubscribe, send any mail to "freebsd-ppc-unsubscribe at freebsd.org"
>
More information about the freebsd-ppc
mailing list