From owner-freebsd-ppc@freebsd.org Sun May 7 01:53:37 2017 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 95587D5F503 for ; Sun, 7 May 2017 01:53:37 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-77.reflexion.net [208.70.210.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 00534116 for ; Sun, 7 May 2017 01:53:36 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 27764 invoked from network); 7 May 2017 01:53:34 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 7 May 2017 01:53:34 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Sat, 06 May 2017 21:53:34 -0400 (EDT) Received: (qmail 11141 invoked from network); 7 May 2017 01:53:34 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 7 May 2017 01:53:34 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id E3711EC808D; Sat, 6 May 2017 18:53:33 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Panics for gcc-4.2.1-based powerpc non-debug head kernel builds (e.g., -r317820); no powerpc kernel debugger support (system or ports) Message-Id: Date: Sat, 6 May 2017 18:53:33 -0700 Cc: FreeBSD Toolchain To: FreeBSD PowerPC ML , freebsd-hackers@freebsd.org X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 May 2017 01:53:37 -0000 [I'm forking off this subject from the llvm bugzilla 26519's latest partial TARET_ARCH=3Dpowerpc fix material as it seems to be independent.] I've recently been building, installing, and using TARGET_ARCH=3Dpowerpc again (because of a partial clang fix for targeting powerpc 32-bit). But the context here can be restricted to just gcc 4.2.1 based builds/installs (world and kernel), head -r317820 most recent tried. [It has been a long time since I'd last built for TARGET_ARCH=3Dpowerpc.] When I run from a debug kernel there has been no observed problems. But running from a production kernel I get occasional panics for "unknown" exceptions. I have cleared out (rm -fr) and rebuilt and reinstalled in case of corruptions, it has not made a difference. I'll note that the same machine does fine with TARGET_ARCH=3Dpowerpc64 builds (system-clang based normally for me). So far all the powerpc panics report: pid=3D11, comm=3Didle: CPU In other words: the [idle{idle: cpu}] threads. Things are unusual in various respects, such as an lr figure that is odd, like 0x907f and exception numbers that are classified as "(unknown)", for example for the number: 0x903a64e . No stack trace is produced. Nearly all the reports claim ffs_truncate+0x1080 for where but I have recently seen something else as well (not recorded, unfortunately). But I'm not sure I'd trust that aspect of the report. Unfortunately calling doadump is not all that useful. Using core.text. to illustrate: # grep unsupported /var/crash/core.txt.5 | more Failed to open vmcore: unsupported architecture ps: unsupported architecture vmstat: kvm_openfiles: unsupported architecture vmstat: kvm_openfiles: unsupported architecture vmstat: kvm_openfiles: unsupported architecture vmstat: kvm_openfiles: unsupported architecture pstat: kvm_openfiles: unsupported architecture pstat: kvm_openfiles: unsupported architecture iostat: kvm_openfiles: unsupported architecture ipcs: kvm_openfiles: unsupported architecture ipcs: kvm_openfiles: unsupported architecture netstat: kvm not available: unsupported architecture netstat: kvm not available: unsupported architecture netstat: kvm not available: unsupported architecture netstat: kvm not available: unsupported architecture netstat: kvm not available: unsupported architecture fstat: kvm_openfiles(): unsupported architecture dmesg: unsupported architecture ddb: ddb_capture: kvm_openfiles: unsupported architecture Only the kernel config section is filled in for core.txt.5 (or the others). And kgdb from devel/gdb (-r440115 of /usr/ports) reports: # kgdb /usr/lib/debug/boot/kernel/kernel.debug /var/crash/vmcore.5=20 . . . Reading symbols from /usr/lib/debug/boot/kernel/kernel.debug...done. ABI doesn't support a vmcore target By contrast with a debug kernel I was able to do buildworld buildkernel from scratch to completion and leave it sit idle for much longer than it has stayed up idle for the production kernel. (The panics are not normally frequent so this takes a while.) If I have a clang based world mixed with the gcc 4.2.1 kernels the same things apply but for powerpc at this point the better context is to stick to just gcc 4.2.1 based builds. The powerpc machine is a old PowerMac. # svnlite status /usr/src/ | sort ? /usr/src/sys/amd64/conf/GENERIC-DBG ? /usr/src/sys/amd64/conf/GENERIC-NODBG ? /usr/src/sys/arm/conf/GENERIC-DBG ? /usr/src/sys/arm/conf/GENERIC-NODBG ? /usr/src/sys/arm64/conf/GENERIC-DBG ? /usr/src/sys/arm64/conf/GENERIC-NODBG ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-DBG ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODBG ? /usr/src/sys/powerpc/conf/GENERICvtsc-DBG ? /usr/src/sys/powerpc/conf/GENERICvtsc-NODBG M /usr/src/contrib/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp M /usr/src/contrib/llvm/tools/lld/ELF/Target.cpp M /usr/src/crypto/openssl/crypto/armcap.c M /usr/src/sys/arm/arm/gic.h M /usr/src/sys/boot/ofw/Makefile.inc M /usr/src/sys/boot/powerpc/Makefile.inc M /usr/src/sys/boot/powerpc/kboot/Makefile M /usr/src/sys/boot/uboot/Makefile.inc M /usr/src/sys/conf/kmod.mk (The Makefile* and *.mk stuff is historical from being compatible with both system and xtoolchain based activity.) I build with both sc and vt but normally use sc via /boot/loader.conf : # more /boot/loader.conf=20 kernel=3D"kernel" verbose_loading=3D"YES" kern.vty=3Dsc dumpdev=3D"/dev/label/FBSDG4Sswap" # more /usr/src/sys/powerpc/conf/GENERICvtsc-NODBG # # GENERIC -- Custom configuration for the powerpc/powerpc # include "GENERIC" ident GENERICvtsc-NODBG makeoptions DEBUG=3D-g # Build kernel with gdb(1) = debug symbols nooptions PS3 # Sony Playstation 3 = HACK!!! to allow sc options KDB # Enable kernel debugger support # For minimum debugger support (stable branch) use: options KDB_TRACE # Print a stack trace for a = panic options DDB # Enable the kernel debugger options GDB # HACK!!! ... # Extra stuff: #options VERBOSE_SYSINIT # Enable verbose sysinit = messages #options BOOTVERBOSE=3D1 #options BOOTHOWTO=3DRB_VERBOSE #options KTR #options KTR_MASK=3DKTR_TRAP ##options KTR_CPUMASK=3D0xF #options KTR_VERBOSE # HACK!!! to allow sc for 2560x1440 display on Radeon X1950 that vt = historically mishandled during booting device sc #device kbdmux # HACK: already listed by vt options SC_OFWFB # OFW frame buffer options SC_DFLT_FONT # compile font in makeoptions SC_DFLT_FONT=3Dcp437 # Disable any extra checking for. . . nooptions DEADLKRES # Enable the deadlock resolver nooptions INVARIANTS # Enable calls of extra sanity = checking nooptions INVARIANT_SUPPORT # Extra sanity checks of = internal structures, required by INVARIANTS nooptions WITNESS # Enable checks to detect = deadlocks and cycles nooptions WITNESS_SKIPSPIN # Don't run witness on spinlocks = for speed nooptions DIAGNOSTIC nooptions MALLOC_DEBUG_MAXZONES # Separate malloc(9) zones I normally run a amd64 -> powerpc cross build, in this case via gcc 4.2.1 : # more ~/src.configs/src.conf.powerpc-gcc421-bootstrap-clang.amd64-host=20= TO_TYPE=3Dpowerpc # KERNCONF=3DGENERICvtsc-NODBG TARGET=3D${TO_TYPE} .if ${.MAKE.LEVEL} =3D=3D 0 TARGET_ARCH=3D${TO_TYPE} .export TARGET_ARCH .endif # WITH_CROSS_COMPILER=3D WITHOUT_SYSTEM_COMPILER=3D # WITHOUT_LIBCPLUSPLUS=3D WITH_BINUTILS_BOOTSTRAP=3D WITH_ELFTOOLCHAIN_BOOTSTRAP=3D WITHOUT_CLANG_BOOTSTRAP=3D WITHOUT_CLANG=3D WITHOUT_CLANG_IS_CC=3D WITHOUT_CLANG_FULL=3D WITHOUT_CLANG_EXTRAS=3D WITHOUT_LLD=3D WITHOUT_LLDB=3D # WITH_BOOT=3D WITHOUT_LIB32=3D # WITH_GCC_BOOTSTRAP=3D WITH_GCC=3D WITH_GCC_IS_CC=3D WITH_GNUCXX=3D # NO_WERROR=3D #WERROR=3D MALLOC_PRODUCTION=3D # WITH_REPRODUCIBLE_BUILD=3D WITH_DEBUG_FILES=3D The amd64 context is also head -r317820 currently. Right now it looks fairly difficult to get a clue about what might be at issue for these panics. =3D=3D=3D Mark Millard markmi at dsl-only.net