From owner-freebsd-ppc@freebsd.org Sun May 7 00:21:13 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 165BBD55520 for ; Sun, 7 May 2017 00:21:13 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-78.reflexion.net [208.70.210.78]) (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 98E5B1722 for ; Sun, 7 May 2017 00:21:11 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 27827 invoked from network); 7 May 2017 00:22:20 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 7 May 2017 00:22:20 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Sat, 06 May 2017 20:21:10 -0400 (EDT) Received: (qmail 8232 invoked from network); 7 May 2017 00:21:10 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 7 May 2017 00:21:10 -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 8B20FEC808D; Sat, 6 May 2017 17:21:09 -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: Lack of TARGET_ARCH=powerpc support in kgdb from devel/gdb (e.g., -r440115 of /usr/ports): "ABI doesn't support a vmcore target" Message-Id: Date: Sat, 6 May 2017 17:21:08 -0700 To: FreeBSD Toolchain , FreeBSD PowerPC ML , FreeBSD Ports 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 00:21:13 -0000 On: # uname -apKU FreeBSD FBSDG4S 12.0-CURRENT FreeBSD 12.0-CURRENT r317820M powerpc = powerpc 1200030 1200030 When I attempt to use: # which kgdb /usr/local/bin/kgdb that was from building devel/gdb for: # svnlite info /usr/ports | grep "Re[plv]" Relative URL: ^/head Repository Root: https://svn.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 440115 Last Changed Rev: 440115 (built via gcc 4.2.1: not via clang: I experiment with clang for powerpc and powerpc64 so I'm being explicit) I end up getting the following sort of result: # kgdb /usr/lib/debug/boot/kernel/kernel.debug /var/crash/vmcore.4=20 . . . Reading symbols from /usr/lib/debug/boot/kernel/kernel.debug...done. ABI doesn't support a vmcore target That message is from: /usr/ports/devel/gdb/files/kgdb/fbsd-kvm.c . . . static void kgdb_trgt_open(const char *arg, int from_tty) { struct fbsd_vmcore_ops *ops =3D (struct fbsd_vmcore_ops *) gdbarch_data (target_gdbarch(), fbsd_vmcore_data); . . . if (ops =3D=3D NULL || ops->supply_pcb =3D=3D NULL || = ops->cpu_pcb_addr =3D=3D NULL) error ("ABI doesn't support a vmcore target"); . . . It appears that there is no kernel debugging supported for TARGET_ARCH=3Dpowerpc currently. (The system no longer has its own gdb related materials.) =3D=3D=3D Mark Millard markmi at dsl-only.net 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 From owner-freebsd-ppc@freebsd.org Sun May 7 05:04:02 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 255A4D626B6 for ; Sun, 7 May 2017 05:04:02 +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 A209E145E for ; Sun, 7 May 2017 05:04:00 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 29163 invoked from network); 7 May 2017 05:07:21 -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 05:07:21 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Sun, 07 May 2017 01:03:59 -0400 (EDT) Received: (qmail 6106 invoked from network); 7 May 2017 05:03:59 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 7 May 2017 05:03:59 -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 6FC5FEC8F8E; Sat, 6 May 2017 22:03:58 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Lack of TARGET_ARCH=powerpc support in kgdb from devel/gdb (e.g., -r440115 of /usr/ports): "ABI doesn't support a vmcore target" From: Mark Millard In-Reply-To: Date: Sat, 6 May 2017 22:03:57 -0700 Cc: FreeBSD Ports , andreast@FreeBSD.org, John Baldwin Content-Transfer-Encoding: quoted-printable Message-Id: <568491A5-0BDC-41CD-945C-E42B53EC2393@dsl-only.net> References: To: FreeBSD Toolchain , FreeBSD PowerPC ML 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 05:04:02 -0000 On 2017-May-6, at 5:21 PM, Mark Millard wrote: > On: >=20 > # uname -apKU > FreeBSD FBSDG4S 12.0-CURRENT FreeBSD 12.0-CURRENT r317820M powerpc = powerpc 1200030 1200030 >=20 > When I attempt to use: >=20 > # which kgdb > /usr/local/bin/kgdb >=20 > that was from building devel/gdb for: >=20 > # svnlite info /usr/ports | grep "Re[plv]" > Relative URL: ^/head > Repository Root: https://svn.freebsd.org/ports > Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 > Revision: 440115 > Last Changed Rev: 440115 >=20 > (built via gcc 4.2.1: not via clang: I > experiment with clang for powerpc and > powerpc64 so I'm being explicit) >=20 > I end up getting the following sort of result: >=20 > # kgdb /usr/lib/debug/boot/kernel/kernel.debug /var/crash/vmcore.4=20 > . . . > Reading symbols from /usr/lib/debug/boot/kernel/kernel.debug...done. > ABI doesn't support a vmcore target >=20 > That message is from: /usr/ports/devel/gdb/files/kgdb/fbsd-kvm.c . . . >=20 > static void > kgdb_trgt_open(const char *arg, int from_tty) > { > struct fbsd_vmcore_ops *ops =3D (struct fbsd_vmcore_ops *) > gdbarch_data (target_gdbarch(), fbsd_vmcore_data); > . . . > if (ops =3D=3D NULL || ops->supply_pcb =3D=3D NULL || = ops->cpu_pcb_addr =3D=3D NULL) > error ("ABI doesn't support a vmcore target"); > . . . >=20 > It appears that there is no kernel debugging > supported for TARGET_ARCH=3Dpowerpc currently. > (The system no longer has its own gdb related > materials.) I've discovered more context and have found a few of issues in how things are currently set up. THING #0: It appears that usr.sbin/crashinfo/crashinfo.sh assumes that /usr/local/bin/gdb will work better for all architectures, including for kgdb types of activity: find_gdb() { local binary for binary in /usr/local/bin/gdb /usr/libexec/gdb /usr/bin/gdb; = do if [ -x ${binary} ]; then GDB=3D${binary} return fi done } But it appears that on powerpc /usr/local/bin/gdb and /usr/local/bin/kgdb do not support TARGET_ARCH=3Dpowerpc at all for such activity. THING #1: Another oddity is for the combination: ${MK_GDB} =3D=3D no && ${MK_GDB_LIBEXEC} =3D=3D yes where the tools/build/mk/OptionalObsoleteFiles.inc logic then adds the libexec gdb and kgdb to OLD_FILES : .if ${MK_GDB} =3D=3D no || ${MK_GDB_LIBEXEC} =3D=3D no OLD_FILES+=3Dusr/libexec/gdb OLD_FILES+=3Dusr/libexec/kgdb .endif so doing a delete-old removes the only system gdb and kgdb that are installed for such a context. It does this because of: ${MK_GDB} =3D=3D no (And that explains why I thought gdb and kgdb were not in the system.) THING #2: /usr/libexec/kgdb (when present) does not support the powerpc architecture for head either . . . On a head -r317820 powerpc I attempted: # /usr/libexec/kgdb /usr/lib/debug/boot/kernel/kernel.debug = /var/crash/vmcore.7 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you = are welcome to change it and/or distribute copies of it under certain = conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for = details. This GDB was configured as "powerpc-marcel-freebsd"... Failed to open vmcore: unsupported architecture =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Sun May 7 19:21:45 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 3DBC3D6278D for ; Sun, 7 May 2017 19:21:45 +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 C219415F8 for ; Sun, 7 May 2017 19:21:44 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 17237 invoked from network); 7 May 2017 19:22:48 -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 19:22:48 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Sun, 07 May 2017 15:21:37 -0400 (EDT) Received: (qmail 20447 invoked from network); 7 May 2017 19:21:37 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 7 May 2017 19:21:37 -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 3452AEC8809; Sun, 7 May 2017 12:21:36 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Lack of TARGET_ARCH=powerpc support in kgdb from devel/gdb (e.g., -r440115 of /usr/ports): "ABI doesn't support a vmcore target" From: Mark Millard In-Reply-To: <568491A5-0BDC-41CD-945C-E42B53EC2393@dsl-only.net> Date: Sun, 7 May 2017 12:21:35 -0700 Cc: FreeBSD Ports , andreast@FreeBSD.org, John Baldwin Content-Transfer-Encoding: quoted-printable Message-Id: <540903B2-A752-49D9-9833-42C7AC87089F@dsl-only.net> References: <568491A5-0BDC-41CD-945C-E42B53EC2393@dsl-only.net> To: FreeBSD Toolchain , FreeBSD PowerPC ML 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 19:21:45 -0000 [This update just notes that it appears that combination ${MK_GDB} =3D=3D no && ${MK_GDB_LIBEXEC} =3D=3D yes is not intended to be used, effectively eliminating "THING #1" of 0-2.] On 2017-May-6, at 10:03 PM, Mark Millard wrote: > On 2017-May-6, at 5:21 PM, Mark Millard = wrote: >=20 >> On: >>=20 >> # uname -apKU >> FreeBSD FBSDG4S 12.0-CURRENT FreeBSD 12.0-CURRENT r317820M powerpc = powerpc 1200030 1200030 >>=20 >> When I attempt to use: >>=20 >> # which kgdb >> /usr/local/bin/kgdb >>=20 >> that was from building devel/gdb for: >>=20 >> # svnlite info /usr/ports | grep "Re[plv]" >> Relative URL: ^/head >> Repository Root: https://svn.freebsd.org/ports >> Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 >> Revision: 440115 >> Last Changed Rev: 440115 >>=20 >> (built via gcc 4.2.1: not via clang: I >> experiment with clang for powerpc and >> powerpc64 so I'm being explicit) >>=20 >> I end up getting the following sort of result: >>=20 >> # kgdb /usr/lib/debug/boot/kernel/kernel.debug /var/crash/vmcore.4=20 >> . . . >> Reading symbols from /usr/lib/debug/boot/kernel/kernel.debug...done. >> ABI doesn't support a vmcore target >>=20 >> That message is from: /usr/ports/devel/gdb/files/kgdb/fbsd-kvm.c . . = . >>=20 >> static void >> kgdb_trgt_open(const char *arg, int from_tty) >> { >> struct fbsd_vmcore_ops *ops =3D (struct fbsd_vmcore_ops *) >> gdbarch_data (target_gdbarch(), fbsd_vmcore_data); >> . . . >> if (ops =3D=3D NULL || ops->supply_pcb =3D=3D NULL || = ops->cpu_pcb_addr =3D=3D NULL) >> error ("ABI doesn't support a vmcore target"); >> . . . >>=20 >> It appears that there is no kernel debugging >> supported for TARGET_ARCH=3Dpowerpc currently. >> (The system no longer has its own gdb related >> materials.) >=20 > I've discovered more context and have found > a few of issues in how things are currently > set up. >=20 > THING #0: >=20 > It appears that usr.sbin/crashinfo/crashinfo.sh assumes > that /usr/local/bin/gdb will work better for all architectures, > including for kgdb types of activity: >=20 > find_gdb() > { > local binary >=20 > for binary in /usr/local/bin/gdb /usr/libexec/gdb /usr/bin/gdb; = do > if [ -x ${binary} ]; then > GDB=3D${binary} > return > fi > done > } >=20 > But it appears that on powerpc /usr/local/bin/gdb and > /usr/local/bin/kgdb do not support TARGET_ARCH=3Dpowerpc > at all for such activity. >=20 >=20 > THING #1: >=20 > Another oddity is for the combination: >=20 > ${MK_GDB} =3D=3D no && ${MK_GDB_LIBEXEC} =3D=3D yes >=20 > where the tools/build/mk/OptionalObsoleteFiles.inc > logic then adds the libexec gdb and kgdb to > OLD_FILES : >=20 > .if ${MK_GDB} =3D=3D no || ${MK_GDB_LIBEXEC} =3D=3D no > OLD_FILES+=3Dusr/libexec/gdb > OLD_FILES+=3Dusr/libexec/kgdb > .endif >=20 > so doing a delete-old removes the only system > gdb and kgdb that are installed for such a > context. It does this because of: >=20 > ${MK_GDB} =3D=3D no >=20 > (And that explains why I thought gdb and kgdb > were not in the system.) Looking around at how WITH_GDB and WITH_GDB_LIBEXEC and the MK_ variants are used it appears that the: ${MK_GDB} =3D=3D no && ${MK_GDB_LIBEXEC} =3D=3D yes combination is not intended to be used. > THING #2: >=20 > /usr/libexec/kgdb (when present) does not support the > powerpc architecture for head either . . . >=20 > On a head -r317820 powerpc I attempted: >=20 > # /usr/libexec/kgdb /usr/lib/debug/boot/kernel/kernel.debug = /var/crash/vmcore.7 > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and = you are > welcome to change it and/or distribute copies of it under certain = conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for = details. > This GDB was configured as "powerpc-marcel-freebsd"... > Failed to open vmcore: unsupported architecture =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Mon May 8 19:06:27 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 2E9DCD63A11; Mon, 8 May 2017 19:06:27 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5B5D017A2; Mon, 8 May 2017 19:06:26 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by mail.baldwin.cx (Postfix) with ESMTPSA id 5BE7A10A7B9; Mon, 8 May 2017 15:06:18 -0400 (EDT) From: John Baldwin To: Mark Millard Cc: FreeBSD Toolchain , FreeBSD PowerPC ML , FreeBSD Ports , andreast@freebsd.org Subject: Re: Lack of TARGET_ARCH=powerpc support in kgdb from devel/gdb (e.g., -r440115 of /usr/ports): "ABI doesn't support a vmcore target" Date: Mon, 08 May 2017 11:30:53 -0700 Message-ID: <2567165.qjEVz8HF8R@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.0-STABLE; KDE/4.14.10; amd64; ; ) In-Reply-To: <568491A5-0BDC-41CD-945C-E42B53EC2393@dsl-only.net> References: <568491A5-0BDC-41CD-945C-E42B53EC2393@dsl-only.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Mon, 08 May 2017 15:06:18 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean 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: Mon, 08 May 2017 19:06:27 -0000 On Saturday, May 06, 2017 10:03:57 PM Mark Millard wrote: > THING #0: > > It appears that usr.sbin/crashinfo/crashinfo.sh assumes > that /usr/local/bin/gdb will work better for all architectures, > including for kgdb types of activity: > > find_gdb() > { > local binary > > for binary in /usr/local/bin/gdb /usr/libexec/gdb /usr/bin/gdb; do > if [ -x ${binary} ]; then > GDB=${binary} > return > fi > done > } > > But it appears that on powerpc /usr/local/bin/gdb and > /usr/local/bin/kgdb do not support TARGET_ARCH=powerpc > at all for such activity. Not really. kgdb on powerpc doesn't work period as neither the base nor ports kgdb can unwind a stack frame. I spent some time last year trying to get the unwind out of cpu_switch() to work to no avail. The current hack attempts are here: https://github.com/bsdjhb/gdb/compare/freebsd-7.11-kgdb...kgdb-ppc > THING #1: > > Another oddity is for the combination: > > ${MK_GDB} == no && ${MK_GDB_LIBEXEC} == yes As I think you figured out, MK_GDB_LIBEXEC depends on MK_GDB=yes. If WITHOUT_GDB=yes is set, then no "base" GDB is installed at all. WITH_GDB_LIBEXEC is just to decide in the MK_GDB=yes case where "base" GDB goes: /usr/bin vs /usr/libexec. > THING #2: > > /usr/libexec/kgdb (when present) does not support the > powerpc architecture for head either . . . > > On a head -r317820 powerpc I attempted: > > # /usr/libexec/kgdb /usr/lib/debug/boot/kernel/kernel.debug /var/crash/vmcore.7 > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "powerpc-marcel-freebsd"... > Failed to open vmcore: unsupported architecture This is a different problem with libkvm. I would start with 'ps -M' and use a debugger to step through the _powerpc_probe and _powerpc64_probe routines in libkvm to see why the appropriate probe routine isn't claiming the core. -- John Baldwin From owner-freebsd-ppc@freebsd.org Mon May 8 20:25:06 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 3BDA4D62AEF for ; Mon, 8 May 2017 20:25:06 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-91.reflexion.net [208.70.210.91]) (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 B889D151 for ; Mon, 8 May 2017 20:25:05 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 21104 invoked from network); 8 May 2017 20:18:24 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 8 May 2017 20:18:24 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Mon, 08 May 2017 16:18:24 -0400 (EDT) Received: (qmail 21383 invoked from network); 8 May 2017 20:18:23 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 8 May 2017 20:18:23 -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 57C0BEC881F; Mon, 8 May 2017 13:18:22 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Lack of TARGET_ARCH=powerpc support in kgdb from devel/gdb (e.g., -r440115 of /usr/ports): "ABI doesn't support a vmcore target" From: Mark Millard In-Reply-To: <2567165.qjEVz8HF8R@ralph.baldwin.cx> Date: Mon, 8 May 2017 13:18:21 -0700 Cc: FreeBSD Toolchain , FreeBSD PowerPC ML , FreeBSD Ports , andreast@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <3A7CC677-0946-4BF3-8622-530BF274605F@dsl-only.net> References: <568491A5-0BDC-41CD-945C-E42B53EC2393@dsl-only.net> <2567165.qjEVz8HF8R@ralph.baldwin.cx> To: John Baldwin 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: Mon, 08 May 2017 20:25:06 -0000 [Mostly: Why THING #2 fails: checks for ET_EXEC but the actual vmcore.* 's have ET_DYN instead.] On 2017-May-8, at 11:30 AM, John Baldwin wrote: > On Saturday, May 06, 2017 10:03:57 PM Mark Millard wrote: >> THING #0: >>=20 >> It appears that usr.sbin/crashinfo/crashinfo.sh assumes >> that /usr/local/bin/gdb will work better for all architectures, >> including for kgdb types of activity: >>=20 >> find_gdb() >> { >> local binary >>=20 >> for binary in /usr/local/bin/gdb /usr/libexec/gdb = /usr/bin/gdb; do >> if [ -x ${binary} ]; then >> GDB=3D${binary} >> return >> fi >> done >> } >>=20 >> But it appears that on powerpc /usr/local/bin/gdb and >> /usr/local/bin/kgdb do not support TARGET_ARCH=3Dpowerpc >> at all for such activity. >=20 > Not really. kgdb on powerpc doesn't work period as neither the base = nor ports > kgdb can unwind a stack frame. I spent some time last year trying to = get the > unwind out of cpu_switch() to work to no avail. The current hack = attempts are > here: >=20 > https://github.com/bsdjhb/gdb/compare/freebsd-7.11-kgdb...kgdb-ppc Interesting. >> THING #1: >> . . . >=20 >> THING #2: >>=20 >> /usr/libexec/kgdb (when present) does not support the >> powerpc architecture for head either . . . >>=20 >> On a head -r317820 powerpc I attempted: >>=20 >> # /usr/libexec/kgdb /usr/lib/debug/boot/kernel/kernel.debug = /var/crash/vmcore.7 >> GNU gdb 6.1.1 [FreeBSD] >> Copyright 2004 Free Software Foundation, Inc. >> GDB is free software, covered by the GNU General Public License, and = you are >> welcome to change it and/or distribute copies of it under certain = conditions. >> Type "show copying" to see the conditions. >> There is absolutely no warranty for GDB. Type "show warranty" for = details. >> This GDB was configured as "powerpc-marcel-freebsd"... >> Failed to open vmcore: unsupported architecture >=20 > This is a different problem with libkvm. I would start with 'ps -M' = and use > a debugger to step through the _powerpc_probe and _powerpc64_probe = routines in > libkvm to see why the appropriate probe routine isn't claiming the = core. For THING #2: I had to use /usr/libexec/gdb as the debugger because /usr/local/bin/gdb segmentation faulted. (gdb) list 126 int 127 _kvm_probe_elf_kernel(kvm_t *kd, int class, int machine) 128 { 129=09 130 return (kd->nlehdr.e_ident[EI_CLASS] =3D=3D class && 131 kd->nlehdr.e_type =3D=3D ET_EXEC && 132 kd->nlehdr.e_machine =3D=3D machine); 133 } gets false via: kd->nlehdr.e_type =3D=3D ET_EXEC (gdb) print kd->nlehdr.e_type $4 =3D 3 but the comparison is for: 0x41882fe0 <_kvm_probe_elf_kernel+32>: cmplwi cr1,r4,2 (gdb) disass Dump of assembler code for function _kvm_probe_elf_kernel: 0x41882fc0 <_kvm_probe_elf_kernel+0>: stwu r1,-16(r1) 0x41882fc4 <_kvm_probe_elf_kernel+4>: stw r31,12(r1) 0x41882fc8 <_kvm_probe_elf_kernel+8>: mr r31,r1 0x41882fcc <_kvm_probe_elf_kernel+12>: lbz r6,2076(r3) 0x41882fd0 <_kvm_probe_elf_kernel+16>: crclr eq 0x41882fd4 <_kvm_probe_elf_kernel+20>: cmplw cr1,r6,r4 0x41882fd8 <_kvm_probe_elf_kernel+24>: bne- cr1,0x41882ff0 = <_kvm_probe_elf_kernel+48> 0x41882fdc <_kvm_probe_elf_kernel+28>: lhz r4,2088(r3) 0x41882fe0 <_kvm_probe_elf_kernel+32>: cmplwi cr1,r4,2 0x41882fe4 <_kvm_probe_elf_kernel+36>: bne- cr1,0x41882ff0 = <_kvm_probe_elf_kernel+48> 0x41882fe8 <_kvm_probe_elf_kernel+40>: lhz r3,2090(r3) 0x41882fec <_kvm_probe_elf_kernel+44>: cmpw r3,r5 0x41882ff0 <_kvm_probe_elf_kernel+48>: li r3,1 0x41882ff4 <_kvm_probe_elf_kernel+52>: beq- 0x41882ffc = <_kvm_probe_elf_kernel+60> 0x41882ff8 <_kvm_probe_elf_kernel+56>: li r3,0 0x41882ffc <_kvm_probe_elf_kernel+60>: lwz r31,12(r1) 0x41883000 <_kvm_probe_elf_kernel+64>: addi r1,r1,16 0x41883004 <_kvm_probe_elf_kernel+68>: blr powerpc and powerpc64 use position independent kernels these days as I remember, making kd->nlehdr.e_type be ET_DYN instead of ET_EXEC : /* e_type */ #define ET_REL 1 #define ET_EXEC 2 #define ET_DYN 3 #define ET_CORE 4 I do not know if more needs to change than just the enabling test since the content is ET_DYN type of material. It looks like the conversion to position independent kernels for powerpc and powerpc64 did not cover all the related infrastructure, such as libkvm. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Mon May 8 21:36:57 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 898EDD64401 for ; Mon, 8 May 2017 21:36:57 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-90.reflexion.net [208.70.210.90]) (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 3EFE595A for ; Mon, 8 May 2017 21:36:56 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 6958 invoked from network); 8 May 2017 21:36:55 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 8 May 2017 21:36:55 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Mon, 08 May 2017 17:36:55 -0400 (EDT) Received: (qmail 9323 invoked from network); 8 May 2017 21:36:55 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 8 May 2017 21:36:55 -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 B702CEC9220; Mon, 8 May 2017 14:36:54 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Lack of TARGET_ARCH=powerpc support in kgdb from devel/gdb (e.g., -r440115 of /usr/ports): "ABI doesn't support a vmcore target" From: Mark Millard In-Reply-To: <3A7CC677-0946-4BF3-8622-530BF274605F@dsl-only.net> Date: Mon, 8 May 2017 14:36:54 -0700 Cc: FreeBSD Toolchain , andreast@freebsd.org, FreeBSD Ports , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: <599466E6-DDFB-4C94-B16D-B0F5CA787431@dsl-only.net> References: <568491A5-0BDC-41CD-945C-E42B53EC2393@dsl-only.net> <2567165.qjEVz8HF8R@ralph.baldwin.cx> <3A7CC677-0946-4BF3-8622-530BF274605F@dsl-only.net> To: John Baldwin 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: Mon, 08 May 2017 21:36:57 -0000 [I've submitted bugzilla 219153 for this libvm issue of not handling powerpc's/powerp64's ET_DYN vmcore.* 's and such.] On 2017-May-8, at 1:18 PM, Mark Millard wrote: > [Mostly: Why THING #2 fails: checks for ET_EXEC > but the actual vmcore.* 's have ET_DYN instead.] >=20 > On 2017-May-8, at 11:30 AM, John Baldwin wrote: >=20 >> On Saturday, May 06, 2017 10:03:57 PM Mark Millard wrote: >>> THING #0: >>>=20 >>> It appears that usr.sbin/crashinfo/crashinfo.sh assumes >>> that /usr/local/bin/gdb will work better for all architectures, >>> including for kgdb types of activity: >>>=20 >>> find_gdb() >>> { >>> local binary >>>=20 >>> for binary in /usr/local/bin/gdb /usr/libexec/gdb = /usr/bin/gdb; do >>> if [ -x ${binary} ]; then >>> GDB=3D${binary} >>> return >>> fi >>> done >>> } >>>=20 >>> But it appears that on powerpc /usr/local/bin/gdb and >>> /usr/local/bin/kgdb do not support TARGET_ARCH=3Dpowerpc >>> at all for such activity. >>=20 >> Not really. kgdb on powerpc doesn't work period as neither the base = nor ports >> kgdb can unwind a stack frame. I spent some time last year trying to = get the >> unwind out of cpu_switch() to work to no avail. The current hack = attempts are >> here: >>=20 >> https://github.com/bsdjhb/gdb/compare/freebsd-7.11-kgdb...kgdb-ppc >=20 > Interesting. >=20 >>> THING #1: >>> . . . >>=20 >>> THING #2: >>>=20 >>> /usr/libexec/kgdb (when present) does not support the >>> powerpc architecture for head either . . . >>>=20 >>> On a head -r317820 powerpc I attempted: >>>=20 >>> # /usr/libexec/kgdb /usr/lib/debug/boot/kernel/kernel.debug = /var/crash/vmcore.7 >>> GNU gdb 6.1.1 [FreeBSD] >>> Copyright 2004 Free Software Foundation, Inc. >>> GDB is free software, covered by the GNU General Public License, and = you are >>> welcome to change it and/or distribute copies of it under certain = conditions. >>> Type "show copying" to see the conditions. >>> There is absolutely no warranty for GDB. Type "show warranty" for = details. >>> This GDB was configured as "powerpc-marcel-freebsd"... >>> Failed to open vmcore: unsupported architecture >>=20 >> This is a different problem with libkvm. I would start with 'ps -M' = and use >> a debugger to step through the _powerpc_probe and _powerpc64_probe = routines in >> libkvm to see why the appropriate probe routine isn't claiming the = core. >=20 > For THING #2: >=20 > I had to use /usr/libexec/gdb as the debugger because = /usr/local/bin/gdb > segmentation faulted. >=20 > (gdb) list > 126 int > 127 _kvm_probe_elf_kernel(kvm_t *kd, int class, int machine) > 128 { > 129=09 > 130 return (kd->nlehdr.e_ident[EI_CLASS] =3D=3D class && > 131 kd->nlehdr.e_type =3D=3D ET_EXEC && > 132 kd->nlehdr.e_machine =3D=3D machine); > 133 } >=20 > gets false via: kd->nlehdr.e_type =3D=3D ET_EXEC >=20 > (gdb) print kd->nlehdr.e_type > $4 =3D 3 >=20 > but the comparison is for: >=20 > 0x41882fe0 <_kvm_probe_elf_kernel+32>: cmplwi cr1,r4,2 >=20 > (gdb) disass > Dump of assembler code for function _kvm_probe_elf_kernel: > 0x41882fc0 <_kvm_probe_elf_kernel+0>: stwu r1,-16(r1) > 0x41882fc4 <_kvm_probe_elf_kernel+4>: stw r31,12(r1) > 0x41882fc8 <_kvm_probe_elf_kernel+8>: mr r31,r1 > 0x41882fcc <_kvm_probe_elf_kernel+12>: lbz r6,2076(r3) > 0x41882fd0 <_kvm_probe_elf_kernel+16>: crclr eq > 0x41882fd4 <_kvm_probe_elf_kernel+20>: cmplw cr1,r6,r4 > 0x41882fd8 <_kvm_probe_elf_kernel+24>: bne- cr1,0x41882ff0 = <_kvm_probe_elf_kernel+48> > 0x41882fdc <_kvm_probe_elf_kernel+28>: lhz r4,2088(r3) > 0x41882fe0 <_kvm_probe_elf_kernel+32>: cmplwi cr1,r4,2 > 0x41882fe4 <_kvm_probe_elf_kernel+36>: bne- cr1,0x41882ff0 = <_kvm_probe_elf_kernel+48> > 0x41882fe8 <_kvm_probe_elf_kernel+40>: lhz r3,2090(r3) > 0x41882fec <_kvm_probe_elf_kernel+44>: cmpw r3,r5 > 0x41882ff0 <_kvm_probe_elf_kernel+48>: li r3,1 > 0x41882ff4 <_kvm_probe_elf_kernel+52>: beq- 0x41882ffc = <_kvm_probe_elf_kernel+60> > 0x41882ff8 <_kvm_probe_elf_kernel+56>: li r3,0 > 0x41882ffc <_kvm_probe_elf_kernel+60>: lwz r31,12(r1) > 0x41883000 <_kvm_probe_elf_kernel+64>: addi r1,r1,16 > 0x41883004 <_kvm_probe_elf_kernel+68>: blr >=20 > powerpc and powerpc64 use position independent kernels > these days as I remember, making kd->nlehdr.e_type be > ET_DYN instead of ET_EXEC : >=20 > /* e_type */ > #define ET_REL 1 > #define ET_EXEC 2 > #define ET_DYN 3 > #define ET_CORE 4 >=20 > I do not know if more needs to change than just > the enabling test since the content is ET_DYN > type of material. >=20 > It looks like the conversion to position independent > kernels for powerpc and powerpc64 did not cover all > the related infrastructure, such as libkvm. I've submitted bugzilla 219153 for this libvm issue of not handling powerpc's/powerp64's ET_DYN vmcore.* 's and such. It applies to head , stable/11 , and release/11.0.1 : 20150307: The 32-bit PowerPC kernel has been changed to a = position-independent executable. This can only be booted with a version of loader(8) newer than January 31, 2015, so make sure to update both world = and kernel before rebooting. . . . 20150131: The powerpc64 kernel has been changed to a position-independent executable. This can only be booted with a new version of = loader(8), so make sure to update both world and kernel before rebooting. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Tue May 9 21:00:57 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 55B5BD661E5 for ; Tue, 9 May 2017 21:00:57 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-197.reflexion.net [208.70.211.197]) (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 1BC971BD3 for ; Tue, 9 May 2017 21:00:56 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 6469 invoked from network); 9 May 2017 21:00:55 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 9 May 2017 21:00:55 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Tue, 09 May 2017 17:00:55 -0400 (EDT) Received: (qmail 30197 invoked from network); 9 May 2017 21:00:54 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 9 May 2017 21:00:54 -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 1BE2DEC7B1F; Tue, 9 May 2017 14:00:54 -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: TARGET_ARCH=powerpc head -r317820 production-style kernel: periodic panics always in pid=11 (the Idle threads) Message-Id: <831804AB-1BEB-40C7-BA8B-94DF07E314E5@dsl-only.net> Date: Tue, 9 May 2017 14:00:53 -0700 To: FreeBSD PowerPC ML , FreeBSD Current 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: Tue, 09 May 2017 21:00:57 -0000 kgdb is not working for powerpc, neither system nor ports. I've used "strings" to extract the=20 later information below about the failures. The time frames to failure are widely variable, minutes to hours. I've never seen the below with a debug kernel, only with production-style. I have not seen any such problems for powerpc64, aarch64 (with -mcpu=3Dcortex-a53 ), armv6 (with -mcpu=3Dcortex-a7 ), or amd64. Just powerpc. The powerpc and powerpc64 hardware is (e.g.) the same old PowerMac G5 so-called "Quad Core" used with two different boot SSDs. Note: This reproduces for me for pure gcc 4.2.1 based builds. My usual clang-targetting- powerpc experiments are not involved here. I'd not updated for a long time before this due to the status of the clang compiler not changing and its powerpc stack code-generation problems being difficult to work around. My kernels are unusual by having both sc and vt in the build and ps3 disabled. I happen to be using sc because it works with the 2560x1440 display that is currently connected but with vt it fails to boot for such a size. Of 7 example vmcore.* files. . . (Note that all are pid 11 Idle-process thread failures) 3 contain: fatal kernel trap: exception =3D 0x903a64e (unknown) srr0 =3D 0x7ff760 srr1 =3D 0xc1007c lr =3D 0x907f curthread =3D 0x147d6c0 pid =3D 11, comm =3D idle: cpu0 [ thread pid 11 tid 100003 ] Stopped at ffs_truncate+0x1080: stw r11, 0xf8(r31) 1 contains (cpu1 instead of cpu0, so different tid): fatal kernel trap: exception =3D 0x903a64e (unknown) srr0 =3D 0x7ff760 srr1 =3D 0xc1007c lr =3D 0x907f curthread =3D 0x147d360 pid =3D 11, comm =3D idle: cpu1 [ thread pid 11 tid 100004 ] Stopped at ffs_truncate+0x1080: stw r11, 0xf8(r31) 1 contains: fatal kernel trap: exception =3D 0x21000000 (unknown) srr0 =3D 0x7c0903 srr1 =3D 0xa64e8004 lr =3D 0x807fc9e7 curthread =3D 0x147d000 pid =3D 11, comm =3D idle: cpu2 [ thread pid 11 tid 100005 ] Stopped at audit_commit+0x24f: illegal instruction 4915f00 1 contains: fatal kernel trap: exception =3D 0x300 (data storage interrupt) virtual address =3D 0x7ff76000 dsisr =3D 0x40000000 srr0 =3D 0x8e3cf8 srr1 =3D 0x1032 lr =3D 0x8e3ce8 curthread =3D 0x147d6c0 pid =3D 11, comm =3D idle: cpu0 panic: data storage interrupt trap cpuid =3D 0 time =3D 1494057319 KDB: stack backtrace: 0xdf5e52c0: at kdb_backtrace+0x5c 0xdf5e5330: at vpanic+0x1ec 0xdf5e53a0: at panic+0x54 0xdf5e53f0: at trap_fatal+0x1cc 0xdf5e5420: at trap+0x122c 0xdf5e55c0: at powerpc_interrupt+0x180 0xdf5e55f0: kernel DSI read trap @ 0x7ff76000 by db_disasm+0x30: = srr1=3D0x1032 r1=3D0xdf5e56b0 cr=3D0x24009022 xer=3D0 ctr=3D0x1852cc = sr=3D0x40000000 0xdf5e56b0: at 0x1007460 0xdf5e56d0: at db_print_loc_and_inst+0x60 0xdf5e5700: at db_trap+0x104 0xdf5e5790: at kdb_trap+0x1bc 0xdf5e5810: at trap_fatal+0x1b0 0xdf5e5840: at trap+0x1184 0xdf5e5870: kernel DECR trap by cpu_idle_60x+0x88: srr1=3D0x9032 r1=3D0xdf5e5930 cr=3D0x40000042 xer=3D0x20000000 = ctr=3D0x8e3bd8 saved LR(0xfffffffe) is invalid And 1 contains: fatal kernel trap: exception =3D 0x0 (unknown) srr0 =3D 0x903a64e srr1 =3D 0x80042100 lr =3D 0xc9e7c800 curthread =3D 0x147d360 pid =3D 11, comm =3D idle: cpu1 [ thread pid 11 tid 100004 ] Stopped at 0x903a64e: fatal kernel trap: exception =3D 0x300 (data storage interrupt) virtual address =3D 0x903a64e dsisr =3D 0x40000000 srr0 =3D 0x8e3cf8 srr1 =3D 0x1032 lr =3D 0x8e3ce8 curthread =3D 0x147d360 pid =3D 11, comm =3D idle: cpu1 panic: data storage interrupt trap cpuid =3D 1 time =3D 1494132014 KDB: stack backtrace: 0xdf5ea2c0: at kdb_backtrace+0x5c 0xdf5ea330: at vpanic+0x1ec 0xdf5ea3a0: at panic+0x54 0xdf5ea3f0: at trap_fatal+0x1cc 0xdf5ea420: at trap+0x122c 0xdf5ea5c0: at powerpc_interrupt+0x180 0xdf5ea5f0: kernel DSI read trap @ 0x903a64e by db_disasm+0x30: = srr1=3D0x1032 r1=3D0xdf5ea6b0 cr=3D0x24009022 xer=3D0 ctr=3D0x1852cc = sr=3D0x40000000 0xdf5ea6b0: at 0x1007460 0xdf5ea6d0: at db_print_loc_and_inst+0x60 0xdf5ea700: at db_trap+0x104 0xdf5ea790: at kdb_trap+0x1bc 0xdf5ea810: at trap_fatal+0x1b0 0xdf5ea840: at trap+0x122c 0xdf5ea870: kernel EXI trap by cpu_idle_60x+0x88: srr1=3D0x9032 r1=3D0xdf5ea930 cr=3D0x40000042 xer=3D0x20000000 = ctr=3D0x8e3bd8 saved LR(0x5) is invalid Most (but not all) of the above were while the old PowerMac was sitting unused. The pid 11 Idle thread commonality suggests to me some sort of interrupt oddity messing up when the idle threads were put to use for the interrupt. The /usr/src/sys/powerpc/conf/* files in use are (-NODBG for production style and -DBG for debug style): # more /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODBG # # GENERIC -- Custom configuration for the powerpc/powerpc64 # include "GENERIC64" ident GENERIC64vtsc-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 options ALT_BREAK_TO_DEBUGGER options BREAK_TO_DEBUGGER # 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 show my production (NODBG) and debug (DBG) # 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 options ALT_BREAK_TO_DEBUGGER options BREAK_TO_DEBUGGER # 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 # more /usr/src/sys/powerpc/conf/GENERICvtsc-DBG # # GENERIC -- Custom configuration for the powerpc/powerpc # include "GENERIC" ident GENERICvtsc-DBG 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 options ALT_BREAK_TO_DEBUGGER options BREAK_TO_DEBUGGER # 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|KTR_PROC ##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 # Enable any extra checking for. . . options DEADLKRES # Enable the deadlock resolver options INVARIANTS # Enable calls of extra sanity = checking options INVARIANT_SUPPORT # Extra sanity checks of = internal structures, required by INVARIANTS options WITNESS # Enable checks to detect = deadlocks and cycles options WITNESS_SKIPSPIN # Don't run witness on spinlocks = for speed options DIAGNOSTIC options MALLOC_DEBUG_MAXZONES=3D8 # Separate malloc(9) zones For both -NODBG and -DBG the: options ALT_BREAK_TO_DEBUGGER options BREAK_TO_DEBUGGER are recent additions because of the problem. I explicitly gave myself the option to break to the debugger if I decide to. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Fri May 12 02:55:02 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 E759FD68D82 for ; Fri, 12 May 2017 02:55:02 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B588DB36 for ; Fri, 12 May 2017 02:55:02 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by freefall.freebsd.org (Postfix) id 664A1769C; Fri, 12 May 2017 02:54:57 +0000 (UTC) Delivered-To: freebsd-powerpc@localmail.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by freefall.freebsd.org (Postfix) with ESMTPS id 4FCBA769A for ; Fri, 12 May 2017 02:54:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 947B3AB2 for ; Fri, 12 May 2017 02:54:56 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v4C2sulS099105 for ; Fri, 12 May 2017 02:54:56 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-powerpc@FreeBSD.org Subject: [Bug 217215] graphics/argyllcms broken on powerpc64 Date: Fri, 12 May 2017 02:54:56 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: kwm@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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: Fri, 12 May 2017 02:55:03 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217215 --- Comment #1 from commit-hook@freebsd.org --- A commit references this bug: Author: swills Date: Fri May 12 02:54:44 UTC 2017 New revision: 440675 URL: https://svnweb.freebsd.org/changeset/ports/440675 Log: graphics/argyllcms: Fix build on powerpc64 PR: 217215 [1] PR: 203806 [2] Submitted by: Curtis Hamilton [1] Submitted by: Justin Hibbits [2] Approved by: kwm (maintainer) Changes: head/graphics/argyllcms/Makefile head/graphics/argyllcms/files/patch-Jambase head/graphics/argyllcms/files/patch-ccast_axTLS_os__int.h --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-ppc@freebsd.org Fri May 12 02:56:44 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 BCB25D68DEE for ; Fri, 12 May 2017 02:56:44 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8C407B92 for ; Fri, 12 May 2017 02:56:44 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by freefall.freebsd.org (Postfix) id B1FB476CB; Fri, 12 May 2017 02:56:43 +0000 (UTC) Delivered-To: freebsd-powerpc@localmail.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by freefall.freebsd.org (Postfix) with ESMTPS id 9A7F476C9 for ; Fri, 12 May 2017 02:56:43 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 DF6E1B8D for ; Fri, 12 May 2017 02:56:42 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v4C2ugE1001787 for ; Fri, 12 May 2017 02:56:42 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-powerpc@FreeBSD.org Subject: [Bug 217215] graphics/argyllcms broken on powerpc64 Date: Fri, 12 May 2017 02:56:43 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: swills@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: kwm@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: cc resolution bug_status Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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: Fri, 12 May 2017 02:56:44 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217215 Steve Wills changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |swills@FreeBSD.org Resolution|--- |FIXED Status|New |Closed --- Comment #2 from Steve Wills --- Committed, thanks! --=20 You are receiving this mail because: You are on the CC list for the bug.=