Date: Sat, 6 May 2017 18:53:33 -0700 From: Mark Millard <markmi@dsl-only.net> To: FreeBSD PowerPC ML <freebsd-ppc@freebsd.org>, freebsd-hackers@freebsd.org Cc: FreeBSD Toolchain <freebsd-toolchain@freebsd.org> 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: <DCAAA304-7041-4DCE-91F6-270A09E9AF65@dsl-only.net>
next in thread | raw e-mail | index | archive | help
[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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?DCAAA304-7041-4DCE-91F6-270A09E9AF65>