From owner-freebsd-ppc@FreeBSD.ORG Mon Jan 26 11:25:38 2015 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 310A06B6 for ; Mon, 26 Jan 2015 11:25:38 +0000 (UTC) Received: from asp.reflexion.net (outbound-240.asp.reflexion.net [69.84.129.240]) (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 E200A2EC for ; Mon, 26 Jan 2015 11:25:37 +0000 (UTC) Received: (qmail 17342 invoked from network); 26 Jan 2015 11:25:30 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 26 Jan 2015 11:25:30 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.40.0) with SMTP; Mon, 26 Jan 2015 06:25:30 -0500 (EST) Received: (qmail 2088 invoked from network); 26 Jan 2015 11:25:29 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 26 Jan 2015 11:25:29 -0000 X-No-Relay: not in my network Received: from [192.168.1.8] (c-67-189-19-145.hsd1.or.comcast.net [67.189.19.145]) by iron2.pdx.net (Postfix) with ESMTPSA id DBB0A1C43A7 for ; Mon, 26 Jan 2015 03:25:27 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: 10.1 powerpc64 kernel build/boot-ability oddity (PowerMac):10.1-RELEASE-p4 boots 10.1-STABLE fails to Message-Id: <2B4FCA85-6874-41D8-A093-E87EC96CB5FA@dsl-only.net> Date: Mon, 26 Jan 2015 03:25:27 -0800 To: FreeBSD PowerPC ML Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) X-Mailer: Apple Mail (2.1993) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2015 11:25:38 -0000 I discovered that I have a 10.1 powerpc64 kernel build/boot-ability = oddity (PowerMac). First some context: The builds are/were done on a PowerMac G5 quad-core. $ ls -Fpald /boot/kernel* drwxr-xr-x 2 root wheel 26624 Jan 19 22:26 /boot/kernel/ drwxr-xr-x 2 root wheel 26624 Jan 19 22:26 /boot/kernel.old/ drwxr-xr-x 2 root wheel 26624 Jan 19 22:26 /boot/kernel10.1RE/ drwxr-xr-x 2 root wheel 26624 Jan 23 23:44 /boot/kernel10.1S/ drwxr-xr-x 2 root wheel 26624 Jan 25 19:52 /boot/kernel10.1S-alt/ $ freebsd-version -ku 10.1-RELEASE-p4 10.1-STABLE kernel/, kernel.old/, and kernel10.1RE/ are all copies of each other = currently (cp -xa ...) . It/they are my build of a variant of = 10.1-RELEASE-p4. The other two are builds of variants of 10.1-STABLE = kernels (r276979 and r277483 variants). In this configuration I can boot kernel just fine. I can also stop in = Openfirmware and type any of... boot kernel.old boot kernel10.1RE boot kernel10.1S boot kernel10.1S-alt and the boot works fine and "uname -a" then agrees with whichever one = that I picked. For example boot kernel10.1S-alt results in: $ uname -a FreeBSD FBSDG5M1 10.1-STABLE FreeBSD 10.1-STABLE #8 r277483M: Sun Jan 25 = 19:51:41 PST 2015 root@FBSDG5M1:/usr/obj/usr/src/sys/GENERIC64vtsc = powerpc But if I do either of the following and then try to "shutdown -r now" = afterwards I end up with a decrementer error (sometimes) or addressing = error (the rest of the time, which is most of the time). This is while = openfirmware is still displaying things before I can stop it by typing. = I end up with the options "mac-boot" and "shut-down". cp -ax /boot/kernel10.1S/ /boot/kernel/ cp -ax /boot/kernel10.1S-alt/ /boot/kernel/ Power-off/power-on gets the same kinds of failures that "shutdown -r = now" gets. (Note: I will focus on kernel-10.1S-alt since my source tree = has been updated after I built kernel10.1S so it no longer fully = matches.) Booting from a USB stick instead of the SSD (cmd-option-OF, boot = ud:2,\ppc\bootinfo.txt) and picking shell, doing an appropriate mount, = and then one of cp -ax /boot/kernel.old/ /boot/kernel/ cp -ax /boot/kernel10.1RE/ /boot/kernel/ and then umount and "shutdown -r now" reboots fine and things are back = to normal for future booting. It seems that 10.1-RELEASE-p4 establishes context for 10.1-STABLE that = 10.1-STABLE does not correctly establish for itself --at least in my = builds. But I've no clue what the issue is yet. Context notes: I have multiple source trees (with 10.1-STABLE in /usr/src and the other = elsewhere). I use "make -j 8 kernel KERNCONF=3DGENERIC64vtsc = INSTKERNNAME=3D...". (The later svnlite status "?" lines for any extra = files are not shown.) $ svnlite info ~markmi/src_10_1_releng Path: /home/markmi/src_10_1_releng Working Copy Root Path: /home/markmi/src_10_1_releng URL: https://svn0.us-west.freebsd.org/base/releng/10.1 Relative URL: ^/releng/10.1 Repository Root: https://svn0.us-west.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 277195 Node Kind: directory Schedule: normal Last Changed Author: delphij Last Changed Rev: 277195 Last Changed Date: 2015-01-14 13:27:46 -0800 (Wed, 14 Jan 2015) $ svnlite info /usr/src Path: /usr/src 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: 277483 Node Kind: directory Schedule: normal Last Changed Author: smh Last Changed Rev: 277483 Last Changed Date: 2015-01-21 01:45:48 -0800 (Wed, 21 Jan 2015) $ svnlite status ~markmi/src_10_1_releng M /home/markmi/src_10_1_releng/sys/ddb/db_main.c M /home/markmi/src_10_1_releng/sys/ddb/db_script.c M /home/markmi/src_10_1_releng/sys/powerpc/ofw/ofw_machdep.c M /home/markmi/src_10_1_releng/sys/powerpc/ofw/ofwcall64.S M = /home/markmi/src_10_1_releng/sys/powerpc/powermac/powermac_thermal.c $ svnlite status /usr/src M /usr/src/sys/ddb/db_main.c M /usr/src/sys/ddb/db_script.c M /usr/src/sys/powerpc/ofw/ofw_machdep.c M /usr/src/sys/powerpc/ofw/ofwcall64.S M /usr/src/sys/powerpc/powermac/powermac_thermal.c All of the above except powermac_thermal.c are tied to my trying to = produce evidence for later intermittent PowerMac G5 boot issues than = what I'm reporting here. I will not get into the details for why but = I've set up to use a Justin Hibbits patch for powermac_thermal.c, not = that I need it for the PowerMac that I'm using for this note. (I move = the same SSD around between machines.) I used svnlite diff for each of the above to produce .diff files. = Diffing the .diffs and then then original files is shown below (no = differences). $ diff src10.1-RELENG.diff src10.1-STABLE.diff 3c3 < --- sys/ddb/db_main.c (revision 277195) --- > --- sys/ddb/db_main.c (revision 277483) 27c27 < --- sys/ddb/db_script.c (revision 277195) --- > --- sys/ddb/db_script.c (revision 277483) 57c57 < --- sys/powerpc/ofw/ofw_machdep.c (revision 277195) --- > --- sys/powerpc/ofw/ofw_machdep.c (revision 277483) 73c73 < --- sys/powerpc/ofw/ofwcall64.S (revision 277195) --- > --- sys/powerpc/ofw/ofwcall64.S (revision 277483) 401c401 < --- sys/powerpc/powermac/powermac_thermal.c (revision 277195) --- > --- sys/powerpc/powermac/powermac_thermal.c (revision 277483) $ diff ~markmi/src_10_1_releng/sys/ddb/db_main.c = /usr/src/sys/ddb/db_main.c $ diff ~markmi/src_10_1_releng/sys/ddb/db_script.c = /usr/src/sys/ddb/db_script.c $ diff ~markmi/src_10_1_releng/sys/powerpc/ofw/ofw_machdep.c = /usr/src/sys/powerpc/ofw/ofw_machdep.c $ diff ~markmi/src_10_1_releng/sys/powerpc/ofw/ofwcall64.S = /usr/src/sys/powerpc/ofw/ofwcall64.S $ diff ~markmi/src_10_1_releng/sys/powerpc/powermac/powermac_thermal.c = /usr/src/sys/powerpc/powermac/powermac_thermal.c The same variant of GENERIC64 is used for both the source trees: I call = it GENERIC64vtsc: $ more sys/powerpc/conf/GENERIC64vtsc include GENERIC64 ident GENERIC64vtsc nooptions PS3 #Sony Playstation 3 = HACK!!! to allow sc options DDB # HACK!!! to dump early crash = info (but 11.0-CURRENT already has it) options GDB # HACK!!! ... #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 extra checking typically used for FreeBSD 11.0-CURRENT: 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 MALLOC_DEBUG_MAXZONES # Separate malloc(9) zones (I'm not referring in this Email to the context that I sometimes use the = file content for 11.0-CURRENT. That would be another thing to test but I = have not tried to have my 11.0-CURRENT variant as /boot/kernel/ so far. = But "boot kernel11C" does work when /boot/kernel/ is based on = 10.1-RELEASE-p4.) $ more /etc/make.conf WRKDIRPREFIX=3D/usr/obj/portswork WITH_DEBUG=3D #MALLOC_PRODUCTION=3D $ more /etc/src.conf #WITH_DEBUG_FILES=3D #WITHOUT_CLANG=3D But ~markmi/src_10_1_releng was built longer ago and had the #'s removed = in /etc/src.conf and no MALLOC_PRODUCTION=3D line in /etc/make.conf at = all. (I'll note that I use WITHOUT_CLANG when I use WITH_DEBUG_FILES because = clang fails to fully build otherwise.) $ more /boot/loader.conf verbose_loading=3D"YES" kern.vty=3Dvt =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@FreeBSD.ORG Wed Jan 28 18:16:59 2015 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2DB93AEB for ; Wed, 28 Jan 2015 18:16:59 +0000 (UTC) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (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 13D6F837 for ; Wed, 28 Jan 2015 18:16:58 +0000 (UTC) Received: from comporellon.tachypleus.net (polaris.tachypleus.net [75.101.50.44]) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id t0SIGooZ015095 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 28 Jan 2015 10:16:50 -0800 Message-ID: <54C92792.3010401@freebsd.org> Date: Wed, 28 Jan 2015 10:16:50 -0800 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: freebsd-ppc@freebsd.org Subject: Re: 10.1 powerpc64 kernel build/boot-ability oddity (PowerMac):10.1-RELEASE-p4 boots 10.1-STABLE fails to References: <2B4FCA85-6874-41D8-A093-E87EC96CB5FA@dsl-only.net> In-Reply-To: <2B4FCA85-6874-41D8-A093-E87EC96CB5FA@dsl-only.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVa7sSfoAeo0QgicAslvoHu+ZHDKNVMfBZ/w/ZCRDfEI8Bf59WbUfHuezrWLjOw33VMAhMtp8IifxAY1Rug19KieYYS+3O/pzdI= X-Sonic-ID: C;+mgS1Bmn5BG3xGryCx1YGw== M;viVz1Bmn5BG3xGryCx1YGw== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2015 18:16:59 -0000 This is a bug in loader, unfortunately. Due to the way that it interacts with Open Firmware's memory management, it is not in general possible to change kernels at the loader prompt. Depending on memory layout, sometimes it will work (as you noticed) and sometimes it will enter an inconsistent state, usually crashing very early (as you also noticed). This is the one "known issue" mentioned on the PowerPC port website at http://www.freebsd.org/platforms/ppc.html. -Nathan On 01/26/15 03:25, Mark Millard wrote: > I discovered that I have a 10.1 powerpc64 kernel build/boot-ability oddity (PowerMac). First some context: > > The builds are/were done on a PowerMac G5 quad-core. > > $ ls -Fpald /boot/kernel* > drwxr-xr-x 2 root wheel 26624 Jan 19 22:26 /boot/kernel/ > drwxr-xr-x 2 root wheel 26624 Jan 19 22:26 /boot/kernel.old/ > drwxr-xr-x 2 root wheel 26624 Jan 19 22:26 /boot/kernel10.1RE/ > drwxr-xr-x 2 root wheel 26624 Jan 23 23:44 /boot/kernel10.1S/ > drwxr-xr-x 2 root wheel 26624 Jan 25 19:52 /boot/kernel10.1S-alt/ > $ freebsd-version -ku > 10.1-RELEASE-p4 > 10.1-STABLE > > kernel/, kernel.old/, and kernel10.1RE/ are all copies of each other currently (cp -xa ...) . It/they are my build of a variant of 10.1-RELEASE-p4. The other two are builds of variants of 10.1-STABLE kernels (r276979 and r277483 variants). > > In this configuration I can boot kernel just fine. I can also stop in Openfirmware and type any of... > > boot kernel.old > boot kernel10.1RE > boot kernel10.1S > boot kernel10.1S-alt > > and the boot works fine and "uname -a" then agrees with whichever one that I picked. For example boot kernel10.1S-alt results in: > > $ uname -a > FreeBSD FBSDG5M1 10.1-STABLE FreeBSD 10.1-STABLE #8 r277483M: Sun Jan 25 19:51:41 PST 2015 root@FBSDG5M1:/usr/obj/usr/src/sys/GENERIC64vtsc powerpc > > But if I do either of the following and then try to "shutdown -r now" afterwards I end up with a decrementer error (sometimes) or addressing error (the rest of the time, which is most of the time). This is while openfirmware is still displaying things before I can stop it by typing. I end up with the options "mac-boot" and "shut-down". > > cp -ax /boot/kernel10.1S/ /boot/kernel/ > cp -ax /boot/kernel10.1S-alt/ /boot/kernel/ > > Power-off/power-on gets the same kinds of failures that "shutdown -r now" gets. (Note: I will focus on kernel-10.1S-alt since my source tree has been updated after I built kernel10.1S so it no longer fully matches.) > > Booting from a USB stick instead of the SSD (cmd-option-OF, boot ud:2,\ppc\bootinfo.txt) and picking shell, doing an appropriate mount, and then one of > > cp -ax /boot/kernel.old/ /boot/kernel/ > cp -ax /boot/kernel10.1RE/ /boot/kernel/ > > and then umount and "shutdown -r now" reboots fine and things are back to normal for future booting. > > It seems that 10.1-RELEASE-p4 establishes context for 10.1-STABLE that 10.1-STABLE does not correctly establish for itself --at least in my builds. But I've no clue what the issue is yet. > > > > Context notes: > > I have multiple source trees (with 10.1-STABLE in /usr/src and the other elsewhere). I use "make -j 8 kernel KERNCONF=GENERIC64vtsc INSTKERNNAME=...". (The later svnlite status "?" lines for any extra files are not shown.) > > $ svnlite info ~markmi/src_10_1_releng > Path: /home/markmi/src_10_1_releng > Working Copy Root Path: /home/markmi/src_10_1_releng > URL: https://svn0.us-west.freebsd.org/base/releng/10.1 > Relative URL: ^/releng/10.1 > Repository Root: https://svn0.us-west.freebsd.org/base > Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > Revision: 277195 > Node Kind: directory > Schedule: normal > Last Changed Author: delphij > Last Changed Rev: 277195 > Last Changed Date: 2015-01-14 13:27:46 -0800 (Wed, 14 Jan 2015) > > $ svnlite info /usr/src > Path: /usr/src > 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: 277483 > Node Kind: directory > Schedule: normal > Last Changed Author: smh > Last Changed Rev: 277483 > Last Changed Date: 2015-01-21 01:45:48 -0800 (Wed, 21 Jan 2015) > > $ svnlite status ~markmi/src_10_1_releng > M /home/markmi/src_10_1_releng/sys/ddb/db_main.c > M /home/markmi/src_10_1_releng/sys/ddb/db_script.c > M /home/markmi/src_10_1_releng/sys/powerpc/ofw/ofw_machdep.c > M /home/markmi/src_10_1_releng/sys/powerpc/ofw/ofwcall64.S > M /home/markmi/src_10_1_releng/sys/powerpc/powermac/powermac_thermal.c > $ svnlite status /usr/src > M /usr/src/sys/ddb/db_main.c > M /usr/src/sys/ddb/db_script.c > M /usr/src/sys/powerpc/ofw/ofw_machdep.c > M /usr/src/sys/powerpc/ofw/ofwcall64.S > M /usr/src/sys/powerpc/powermac/powermac_thermal.c > > All of the above except powermac_thermal.c are tied to my trying to produce evidence for later intermittent PowerMac G5 boot issues than what I'm reporting here. I will not get into the details for why but I've set up to use a Justin Hibbits patch for powermac_thermal.c, not that I need it for the PowerMac that I'm using for this note. (I move the same SSD around between machines.) > > I used svnlite diff for each of the above to produce .diff files. Diffing the .diffs and then then original files is shown below (no differences). > > $ diff src10.1-RELENG.diff src10.1-STABLE.diff > 3c3 > < --- sys/ddb/db_main.c (revision 277195) > --- >> --- sys/ddb/db_main.c (revision 277483) > 27c27 > < --- sys/ddb/db_script.c (revision 277195) > --- >> --- sys/ddb/db_script.c (revision 277483) > 57c57 > < --- sys/powerpc/ofw/ofw_machdep.c (revision 277195) > --- >> --- sys/powerpc/ofw/ofw_machdep.c (revision 277483) > 73c73 > < --- sys/powerpc/ofw/ofwcall64.S (revision 277195) > --- >> --- sys/powerpc/ofw/ofwcall64.S (revision 277483) > 401c401 > < --- sys/powerpc/powermac/powermac_thermal.c (revision 277195) > --- >> --- sys/powerpc/powermac/powermac_thermal.c (revision 277483) > $ diff ~markmi/src_10_1_releng/sys/ddb/db_main.c /usr/src/sys/ddb/db_main.c > $ diff ~markmi/src_10_1_releng/sys/ddb/db_script.c /usr/src/sys/ddb/db_script.c > $ diff ~markmi/src_10_1_releng/sys/powerpc/ofw/ofw_machdep.c /usr/src/sys/powerpc/ofw/ofw_machdep.c > $ diff ~markmi/src_10_1_releng/sys/powerpc/ofw/ofwcall64.S /usr/src/sys/powerpc/ofw/ofwcall64.S > $ diff ~markmi/src_10_1_releng/sys/powerpc/powermac/powermac_thermal.c /usr/src/sys/powerpc/powermac/powermac_thermal.c > > The same variant of GENERIC64 is used for both the source trees: I call it GENERIC64vtsc: > > $ more sys/powerpc/conf/GENERIC64vtsc > include GENERIC64 > ident GENERIC64vtsc > > nooptions PS3 #Sony Playstation 3 HACK!!! to allow sc > > options DDB # HACK!!! to dump early crash info (but 11.0-CURRENT already has it) > options GDB # HACK!!! ... > #options KTR > #options KTR_MASK=KTR_TRAP > #options KTR_CPUMASK=0xF > #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=cp437 > > > # Disable extra checking typically used for FreeBSD 11.0-CURRENT: > 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 MALLOC_DEBUG_MAXZONES # Separate malloc(9) zones > > (I'm not referring in this Email to the context that I sometimes use the file content for 11.0-CURRENT. That would be another thing to test but I have not tried to have my 11.0-CURRENT variant as /boot/kernel/ so far. But "boot kernel11C" does work when /boot/kernel/ is based on 10.1-RELEASE-p4.) > > $ more /etc/make.conf > WRKDIRPREFIX=/usr/obj/portswork > WITH_DEBUG= > #MALLOC_PRODUCTION= > $ more /etc/src.conf > #WITH_DEBUG_FILES= > #WITHOUT_CLANG= > > But ~markmi/src_10_1_releng was built longer ago and had the #'s removed in /etc/src.conf and no MALLOC_PRODUCTION= line in /etc/make.conf at all. > > (I'll note that I use WITHOUT_CLANG when I use WITH_DEBUG_FILES because clang fails to fully build otherwise.) > > $ more /boot/loader.conf > verbose_loading="YES" > kern.vty=vt > > === > Mark Millard > markmi at dsl-only.net > > _______________________________________________ > freebsd-ppc@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ppc > To unsubscribe, send any mail to "freebsd-ppc-unsubscribe@freebsd.org" > From owner-freebsd-ppc@FreeBSD.ORG Thu Jan 29 00:36:58 2015 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 10C10956 for ; Thu, 29 Jan 2015 00:36:58 +0000 (UTC) Received: from asp.reflexion.net (outbound-242.asp.reflexion.net [69.84.129.242]) (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 C0324BDE for ; Thu, 29 Jan 2015 00:36:57 +0000 (UTC) Received: (qmail 12406 invoked from network); 29 Jan 2015 00:30:16 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 29 Jan 2015 00:30:16 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.40.0) with SMTP; Wed, 28 Jan 2015 19:30:16 -0500 (EST) Received: (qmail 2957 invoked from network); 29 Jan 2015 00:30:16 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 29 Jan 2015 00:30:16 -0000 X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-67-189-19-145.hsd1.or.comcast.net [67.189.19.145]) by iron2.pdx.net (Postfix) with ESMTPSA id 2EE881C43A2; Wed, 28 Jan 2015 16:30:11 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: On powerpc64 10.1-STABLE portmaster indirectly building devel/powerpc64-gcc fails Date: Wed, 28 Jan 2015 16:30:14 -0800 Message-Id: <81E69CED-2977-4146-A1DA-B199FDAFE146@dsl-only.net> To: FreeBSD PowerPC ML Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-toolchain@freebsd.org X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2015 00:36:58 -0000 I tried to portmaster devel/powerpc64-xtoolchain-gcc but it failed = during the building of powerpc64-gcc with the build reporting 5 missing = files, 4 of which seemed to be different file names used in some places = compared to others and one file apparently built but was not put under = .../work/stage/... . First the basics of my FreeBSD context: $ freebsd-version -ku; uname -a 10.1-RELEASE-p4 10.1-STABLE FreeBSD FBSDG5M1 10.1-RELEASE-p4 FreeBSD 10.1-RELEASE-p4 #1 r277195M: = Mon Jan 26 23:32:28 PST 2015 = root@FBSDG5M1:/usr/obj/usr/home/markmi/src_10_1_releng/sys/GENERIC64vtsc = powerpc (My 10.1 kernel variants are for getting evidence about various PowerMac = G5 Quad-Core boot hangups that happen. Also I have both vt and sc = included because of the mix of display hardware that I have around to = use. So ps3 is disabled to allow sc.) The 10.1-STABLE world build is from -r277483 . (My 10.1-RELEASE-p4 kernel build boots as the default kernel fine = --while my 10.1-STABLE kernel build does not-- both built via the same = r277483 10.1-STABLE world build context. But I can stop the = 10.1-RELEASE-p4 boot during its 10 second wait and then explicitly "boot = kernel10.1S" and that works.) /usr/ports/ "Last Changed Rev" was -r378052 (so from today). For this context "portmaster devel/powerpc64-xtoolchain-gcc" produced = the files: $ ls = /usr/obj/portswork/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/man/= man1/ cpp.1.gz g++.1.gz gcc.1.gz gcov.1.gz but the build later complained about the following being missing in that = directory: powerpc64-portbld-freebsd10.1-cpp.1.gz powerpc64-portbld-freebsd10.1-g++.1.gz powerpc64-portbld-freebsd10.1-gcc.1.gz powerpc64-portbld-freebsd10.1-gcov.1.gz In other words: a difference in if the file-name-prefix = "powerpc64-portbld-freebsd10.1-" is to be there or not. The build also complained about the missing file = /usr/obj/portswork/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/bin/= powerpc64-portbld-freebsd10.1-gcov but what I found relative to gcov was: $ ls = /usr/obj/portswork/usr/ports/devel/powerpc64-gcc/work/build-gcc/gcc/*gco* /usr/obj/portswork/usr/ports/devel/powerpc64-gcc/work/build-gcc/gcc/gcov = /usr/obj/portswork/usr/ports/devel/powerpc64-gcc/work/build-gcc/gcc/gcov-d= ump = /usr/obj/portswork/usr/ports/devel/powerpc64-gcc/work/build-gcc/gcc/gcov-d= ump.o = /usr/obj/portswork/usr/ports/devel/powerpc64-gcc/work/build-gcc/gcc/gcov-i= ov.h = /usr/obj/portswork/usr/ports/devel/powerpc64-gcc/work/build-gcc/gcc/gcov.o= There were none at: $ ls = /usr/obj/portswork/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/bin/= *gco* ls: = /usr/obj/portswork/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/bin/= *gco*: No such file or directory So it appears gcov was built but not staged --yet later was expected to = have been staged. More context details: For the buildworld context: $ svnlite info /usr/src Path: /usr/src 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: 277483 Node Kind: directory Schedule: normal Last Changed Author: smh Last Changed Rev: 277483 Last Changed Date: 2015-01-21 01:45:48 -0800 (Wed, 21 Jan 2015) For the ports: $ svnlite info /usr/ports Path: /usr/ports 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: 378053 Node Kind: directory Schedule: normal Last Changed Author: danilo Last Changed Rev: 378052 Last Changed Date: 2015-01-28 01:33:23 -0800 (Wed, 28 Jan 2015) As for the kernel context (not so relevant here but for completeness): $ svnlite info ~markmi/src_10_1_releng/ Path: /home/markmi/src_10_1_releng Working Copy Root Path: /home/markmi/src_10_1_releng URL: https://svn0.us-west.freebsd.org/base/releng/10.1 Relative URL: ^/releng/10.1 Repository Root: https://svn0.us-west.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 277195 Node Kind: directory Schedule: normal Last Changed Author: delphij Last Changed Rev: 277195 Last Changed Date: 2015-01-14 13:27:46 -0800 (Wed, 14 Jan 2015) $ svnlite status ~markmi/src_10_1_releng/ M /home/markmi/src_10_1_releng/sys/ddb/db_main.c M /home/markmi/src_10_1_releng/sys/ddb/db_script.c M /home/markmi/src_10_1_releng/sys/powerpc/ofw/ofw_machdep.c M /home/markmi/src_10_1_releng/sys/powerpc/ofw/ofwcall64.S M = /home/markmi/src_10_1_releng/sys/powerpc/powermac/powermac_thermal.c (A different PowerMac G5 I had my hands on was having overheating = problems and Justin Hibbits gave me a patch to make the kernel more = aggressive about RPMs for cooling. I move the SSD between G5's and so it = is just part of my general builds for now.) =3D=3D=3D Mark Millard markmi@dsl-only.net From owner-freebsd-ppc@FreeBSD.ORG Thu Jan 29 00:57:49 2015 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E5991BE for ; Thu, 29 Jan 2015 00:57:48 +0000 (UTC) Received: from asp.reflexion.net (outbound-242.asp.reflexion.net [69.84.129.242]) (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 9FA2DDBB for ; Thu, 29 Jan 2015 00:57:48 +0000 (UTC) Received: (qmail 24904 invoked from network); 29 Jan 2015 00:57:47 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 29 Jan 2015 00:57:47 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.40.0) with SMTP; Wed, 28 Jan 2015 19:57:47 -0500 (EST) Received: (qmail 5488 invoked from network); 29 Jan 2015 00:57:46 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 29 Jan 2015 00:57:46 -0000 X-No-Relay: not in my network Received: from [192.168.1.8] (c-67-189-19-145.hsd1.or.comcast.net [67.189.19.145]) by iron2.pdx.net (Postfix) with ESMTPSA id 14C101C43A4 for ; Wed, 28 Jan 2015 16:57:41 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: 10.1 powerpc64 kernel build/boot-ability oddity (PowerMac):10.1-RELEASE-p4 boots 10.1-STABLE fails to From: Mark Millard In-Reply-To: <2B4FCA85-6874-41D8-A093-E87EC96CB5FA@dsl-only.net> Date: Wed, 28 Jan 2015 16:57:45 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <78919D58-B433-404C-ACBD-388EA66B9821@dsl-only.net> References: <2B4FCA85-6874-41D8-A093-E87EC96CB5FA@dsl-only.net> To: FreeBSD PowerPC ML X-Mailer: Apple Mail (2.2070.6) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2015 00:57:49 -0000 I was aware of the issue from the page Nathan referenced but my context = is backwards from the expected issue and from Nathan's wording (below): A) When I do *not* stop it to switch kernels at the loader prompt is = when 10.1-STABLE *crashes*. (True of both loader.conf having kernel=3D set to = pick out /boot/kernel10.1S/ and of cp -ax of 10.1-STABLE to = /boot/kernel/ (with loader.conf defaulted or explicit about /boot/kernel/.) B) When I *do* stop it and explicitly switch from 10.1-RELENG to = 10.1-STABLE at the loader prompt is when it *works* fine for 10.1-STABLE. So far I've tried all my usual permutations of make.conf and src.conf = settings and the behaviors is unchanged across the various builds . I've tried building -r275566, -r276979, and -r477483 of 10.1-STABLE and = they all get the same result in my tests. An interesting point is that across all those 10.1-STABLE builds the = following two lines are always the same for the failure (no variation in = address in SRR0 or in SRR1's value): %SRR0: 00000000.01c277fc %SRR1: 10000000.00003030 It normally says "Invalid memory address" but occasionally says = "Decrementer exception". I have yet to find a way to build 10.1-STABLE that works for direct = booting but I've no problems with any 10.1-RELENG (or the 10.1-RELEASE) = based builds that I've tried. I'll slowly keep looking into it. (Generally other things are limiting = me to synchronizing world and kernel once and a while for FreeBSD. My = time is mostly going elsewhere still.) > Nathan wrote: >=20 > This is a bug in loader, unfortunately. Due to the way that it = interacts=20 > with Open Firmware's memory management, it is not in general possible = to=20 > change kernels at the loader prompt. Depending on memory layout,=20 > sometimes it will work (as you noticed) and sometimes it will enter an=20= > inconsistent state, usually crashing very early (as you also noticed).=20= > This is the one "known issue" mentioned on the PowerPC port website at=20= > http://www.freebsd.org/platforms/ppc.html. > -Nathan =3D=3D=3D Mark Millard markmi@dsl-only.net On 2015-Jan-26, at 03:25 AM, Mark Millard wrote: I discovered that I have a 10.1 powerpc64 kernel build/boot-ability = oddity (PowerMac). First some context: The builds are/were done on a PowerMac G5 quad-core. $ ls -Fpald /boot/kernel* drwxr-xr-x 2 root wheel 26624 Jan 19 22:26 /boot/kernel/ drwxr-xr-x 2 root wheel 26624 Jan 19 22:26 /boot/kernel.old/ drwxr-xr-x 2 root wheel 26624 Jan 19 22:26 /boot/kernel10.1RE/ drwxr-xr-x 2 root wheel 26624 Jan 23 23:44 /boot/kernel10.1S/ drwxr-xr-x 2 root wheel 26624 Jan 25 19:52 /boot/kernel10.1S-alt/ $ freebsd-version -ku 10.1-RELEASE-p4 10.1-STABLE kernel/, kernel.old/, and kernel10.1RE/ are all copies of each other = currently (cp -xa ...) . It/they are my build of a variant of = 10.1-RELEASE-p4. The other two are builds of variants of 10.1-STABLE = kernels (r276979 and r277483 variants). In this configuration I can boot kernel just fine. I can also stop in = Openfirmware and type any of... boot kernel.old boot kernel10.1RE boot kernel10.1S boot kernel10.1S-alt and the boot works fine and "uname -a" then agrees with whichever one = that I picked. For example boot kernel10.1S-alt results in: $ uname -a FreeBSD FBSDG5M1 10.1-STABLE FreeBSD 10.1-STABLE #8 r277483M: Sun Jan 25 = 19:51:41 PST 2015 root@FBSDG5M1:/usr/obj/usr/src/sys/GENERIC64vtsc = powerpc But if I do either of the following and then try to "shutdown -r now" = afterwards I end up with a decrementer error (sometimes) or addressing = error (the rest of the time, which is most of the time). This is while = openfirmware is still displaying things before I can stop it by typing. = I end up with the options "mac-boot" and "shut-down". cp -ax /boot/kernel10.1S/ /boot/kernel/ cp -ax /boot/kernel10.1S-alt/ /boot/kernel/ Power-off/power-on gets the same kinds of failures that "shutdown -r = now" gets. (Note: I will focus on kernel-10.1S-alt since my source tree = has been updated after I built kernel10.1S so it no longer fully = matches.) Booting from a USB stick instead of the SSD (cmd-option-OF, boot = ud:2,\ppc\bootinfo.txt) and picking shell, doing an appropriate mount, = and then one of cp -ax /boot/kernel.old/ /boot/kernel/ cp -ax /boot/kernel10.1RE/ /boot/kernel/ and then umount and "shutdown -r now" reboots fine and things are back = to normal for future booting. It seems that 10.1-RELEASE-p4 establishes context for 10.1-STABLE that = 10.1-STABLE does not correctly establish for itself --at least in my = builds. But I've no clue what the issue is yet. Context notes: I have multiple source trees (with 10.1-STABLE in /usr/src and the other = elsewhere). I use "make -j 8 kernel KERNCONF=3DGENERIC64vtsc = INSTKERNNAME=3D...". (The later svnlite status "?" lines for any extra = files are not shown.) $ svnlite info ~markmi/src_10_1_releng Path: /home/markmi/src_10_1_releng Working Copy Root Path: /home/markmi/src_10_1_releng URL: https://svn0.us-west.freebsd.org/base/releng/10.1 Relative URL: ^/releng/10.1 Repository Root: https://svn0.us-west.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 277195 Node Kind: directory Schedule: normal Last Changed Author: delphij Last Changed Rev: 277195 Last Changed Date: 2015-01-14 13:27:46 -0800 (Wed, 14 Jan 2015) $ svnlite info /usr/src Path: /usr/src 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: 277483 Node Kind: directory Schedule: normal Last Changed Author: smh Last Changed Rev: 277483 Last Changed Date: 2015-01-21 01:45:48 -0800 (Wed, 21 Jan 2015) $ svnlite status ~markmi/src_10_1_releng M /home/markmi/src_10_1_releng/sys/ddb/db_main.c M /home/markmi/src_10_1_releng/sys/ddb/db_script.c M /home/markmi/src_10_1_releng/sys/powerpc/ofw/ofw_machdep.c M /home/markmi/src_10_1_releng/sys/powerpc/ofw/ofwcall64.S M = /home/markmi/src_10_1_releng/sys/powerpc/powermac/powermac_thermal.c $ svnlite status /usr/src M /usr/src/sys/ddb/db_main.c M /usr/src/sys/ddb/db_script.c M /usr/src/sys/powerpc/ofw/ofw_machdep.c M /usr/src/sys/powerpc/ofw/ofwcall64.S M /usr/src/sys/powerpc/powermac/powermac_thermal.c All of the above except powermac_thermal.c are tied to my trying to = produce evidence for later intermittent PowerMac G5 boot issues than = what I'm reporting here. I will not get into the details for why but = I've set up to use a Justin Hibbits patch for powermac_thermal.c, not = that I need it for the PowerMac that I'm using for this note. (I move = the same SSD around between machines.) I used svnlite diff for each of the above to produce .diff files. = Diffing the .diffs and then then original files is shown below (no = differences). $ diff src10.1-RELENG.diff src10.1-STABLE.diff 3c3 < --- sys/ddb/db_main.c (revision 277195) --- > --- sys/ddb/db_main.c (revision 277483) 27c27 < --- sys/ddb/db_script.c (revision 277195) --- > --- sys/ddb/db_script.c (revision 277483) 57c57 < --- sys/powerpc/ofw/ofw_machdep.c (revision 277195) --- > --- sys/powerpc/ofw/ofw_machdep.c (revision 277483) 73c73 < --- sys/powerpc/ofw/ofwcall64.S (revision 277195) --- > --- sys/powerpc/ofw/ofwcall64.S (revision 277483) 401c401 < --- sys/powerpc/powermac/powermac_thermal.c (revision 277195) --- > --- sys/powerpc/powermac/powermac_thermal.c (revision 277483) $ diff ~markmi/src_10_1_releng/sys/ddb/db_main.c = /usr/src/sys/ddb/db_main.c $ diff ~markmi/src_10_1_releng/sys/ddb/db_script.c = /usr/src/sys/ddb/db_script.c $ diff ~markmi/src_10_1_releng/sys/powerpc/ofw/ofw_machdep.c = /usr/src/sys/powerpc/ofw/ofw_machdep.c $ diff ~markmi/src_10_1_releng/sys/powerpc/ofw/ofwcall64.S = /usr/src/sys/powerpc/ofw/ofwcall64.S $ diff ~markmi/src_10_1_releng/sys/powerpc/powermac/powermac_thermal.c = /usr/src/sys/powerpc/powermac/powermac_thermal.c The same variant of GENERIC64 is used for both the source trees: I call = it GENERIC64vtsc: $ more sys/powerpc/conf/GENERIC64vtsc include GENERIC64 ident GENERIC64vtsc nooptions PS3 #Sony Playstation 3 = HACK!!! to allow sc options DDB # HACK!!! to dump early crash = info (but 11.0-CURRENT already has it) options GDB # HACK!!! ... #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 extra checking typically used for FreeBSD 11.0-CURRENT: 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 MALLOC_DEBUG_MAXZONES # Separate malloc(9) zones (I'm not referring in this Email to the context that I sometimes use the = file content for 11.0-CURRENT. That would be another thing to test but I = have not tried to have my 11.0-CURRENT variant as /boot/kernel/ so far. = But "boot kernel11C" does work when /boot/kernel/ is based on = 10.1-RELEASE-p4.) $ more /etc/make.conf WRKDIRPREFIX=3D/usr/obj/portswork WITH_DEBUG=3D #MALLOC_PRODUCTION=3D $ more /etc/src.conf #WITH_DEBUG_FILES=3D #WITHOUT_CLANG=3D But ~markmi/src_10_1_releng was built longer ago and had the #'s removed = in /etc/src.conf and no MALLOC_PRODUCTION=3D line in /etc/make.conf at = all. (I'll note that I use WITHOUT_CLANG when I use WITH_DEBUG_FILES because = clang fails to fully build otherwise.) $ more /boot/loader.conf verbose_loading=3D"YES" kern.vty=3Dvt =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@FreeBSD.ORG Fri Jan 30 00:56:25 2015 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 99004438; Fri, 30 Jan 2015 00:56:25 +0000 (UTC) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2484A377; Fri, 30 Jan 2015 00:56:25 +0000 (UTC) Received: by mail-we0-f177.google.com with SMTP id l61so24418212wev.8; Thu, 29 Jan 2015 16:56:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=abkHIu+iK0yxS0gBKWIN0y7gcOrx/MTzenlW/8V8ilE=; b=piNmnFwkAFquuTvSnj0RIrhu4kYdzM8I1nY6JrFSZOzQEF3CZWWgYXwfTgsn2Nzi8j yAalNqlfYmk4GZI5cufk7y8m8A23F0/h+fYUwEJP21RJ+BiAZc/d9uw2SawTit016SOs /qa++tuhed0oWDBoxpQCrpYberCp4cfzcLnda+otdBcOS2vUY5I0DJk6kTeecTOWecbq lz1llzcVaJWA7PYD9Pkm3ZNAHXQvSo/qdNfw6avVeIlHH4Ep0N2qCPA4VsZbNT3WrgZy yxJu0XyNztHesrU+PUC2Do45I5YlTzUaAf36f1rK0qYyoriVL0r5hXLEYsECovxC8JHF iPGA== X-Received: by 10.180.8.233 with SMTP id u9mr5327979wia.56.1422579382841; Thu, 29 Jan 2015 16:56:22 -0800 (PST) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id be2sm12603784wjb.38.2015.01.29.16.56.21 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Jan 2015 16:56:22 -0800 (PST) Sender: Baptiste Daroussin Date: Fri, 30 Jan 2015 01:56:19 +0100 From: Baptiste Daroussin To: Mark Millard Subject: Re: On powerpc64 10.1-STABLE portmaster indirectly building devel/powerpc64-gcc fails Message-ID: <20150130005619.GA11558@ivaldir.etoilebsd.net> References: <81E69CED-2977-4146-A1DA-B199FDAFE146@dsl-only.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="fUYQa+Pmc3FrFX/N" Content-Disposition: inline In-Reply-To: <81E69CED-2977-4146-A1DA-B199FDAFE146@dsl-only.net> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-toolchain@freebsd.org, FreeBSD PowerPC ML X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jan 2015 00:56:25 -0000 --fUYQa+Pmc3FrFX/N Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 28, 2015 at 04:30:14PM -0800, Mark Millard wrote: > I tried to portmaster devel/powerpc64-xtoolchain-gcc but it failed during= the building of powerpc64-gcc with the build reporting 5 missing files, 4 = of which seemed to be different file names used in some places compared to = others and one file apparently built but was not put under .../work/stage/.= =2E. . >=20 > First the basics of my FreeBSD context: >=20 > $ freebsd-version -ku; uname -a > 10.1-RELEASE-p4 > 10.1-STABLE > FreeBSD FBSDG5M1 10.1-RELEASE-p4 FreeBSD 10.1-RELEASE-p4 #1 r277195M: Mon= Jan 26 23:32:28 PST 2015 root@FBSDG5M1:/usr/obj/usr/home/markmi/src_10= _1_releng/sys/GENERIC64vtsc powerpc >=20 > (My 10.1 kernel variants are for getting evidence about various PowerMac = G5 Quad-Core boot hangups that happen. Also I have both vt and sc included = because of the mix of display hardware that I have around to use. So ps3 is= disabled to allow sc.) >=20 > The 10.1-STABLE world build is from -r277483 . >=20 > (My 10.1-RELEASE-p4 kernel build boots as the default kernel fine --while= my 10.1-STABLE kernel build does not-- both built via the same r277483 10.= 1-STABLE world build context. But I can stop the 10.1-RELEASE-p4 boot durin= g its 10 second wait and then explicitly "boot kernel10.1S" and that works.) >=20 > /usr/ports/ "Last Changed Rev" was -r378052 (so from today). >=20 powerpc64-xtoolchain-gcc is an external toolchain to cross build base with recent gcc is that what you want? (in anycase it should not fail :) I'll investigate) Bapt --fUYQa+Pmc3FrFX/N Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlTK1rMACgkQ8kTtMUmk6ExPPgCeJ9J5pKi7T3fHAFwoVJI8DAtj ioMAn0Sv1RoDN6n7rnfE/mqVnGDZ3yJu =jxKH -----END PGP SIGNATURE----- --fUYQa+Pmc3FrFX/N-- From owner-freebsd-ppc@FreeBSD.ORG Fri Jan 30 01:19:47 2015 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0F629AB5 for ; Fri, 30 Jan 2015 01:19:47 +0000 (UTC) Received: from asp.reflexion.net (outbound-242.asp.reflexion.net [69.84.129.242]) (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 A74707B3 for ; Fri, 30 Jan 2015 01:19:46 +0000 (UTC) Received: (qmail 7159 invoked from network); 30 Jan 2015 01:19:39 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 30 Jan 2015 01:19:39 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.40.0) with SMTP; Thu, 29 Jan 2015 20:19:39 -0500 (EST) Received: (qmail 3603 invoked from network); 30 Jan 2015 01:19:38 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 30 Jan 2015 01:19:38 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-67-189-19-145.hsd1.or.comcast.net [67.189.19.145]) by iron2.pdx.net (Postfix) with ESMTPSA id 2391B1C43AC; Thu, 29 Jan 2015 17:19:33 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: On powerpc64 10.1-STABLE portmaster indirectly building devel/powerpc64-gcc fails From: Mark Millard In-Reply-To: <20150130005619.GA11558@ivaldir.etoilebsd.net> Date: Thu, 29 Jan 2015 17:19:36 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <89F97E94-AB9F-46C0-9AA2-C4D0680D64E7@dsl-only.net> References: <81E69CED-2977-4146-A1DA-B199FDAFE146@dsl-only.net> <20150130005619.GA11558@ivaldir.etoilebsd.net> To: Baptiste Daroussin X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-toolchain@freebsd.org, FreeBSD PowerPC ML X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jan 2015 01:19:47 -0000 For me trying powerpc64-xtoolchain-gcc was just an initial experiment = for personal interest, even though if I used it I'd be "cross" building = back to powerpc64 with the modern gcc for now. No grand disaster for me = if building it does not work for a while. But finding the issues and reporting them means the experiment has = provided a useful result already. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Jan-29, at 04:56 PM, Baptiste Daroussin = wrote: On Wed, Jan 28, 2015 at 04:30:14PM -0800, Mark Millard wrote: > I tried to portmaster devel/powerpc64-xtoolchain-gcc but it failed = during the building of powerpc64-gcc with the build reporting 5 missing = files, 4 of which seemed to be different file names used in some places = compared to others and one file apparently built but was not put under = .../work/stage/... . >=20 > First the basics of my FreeBSD context: >=20 > $ freebsd-version -ku; uname -a > 10.1-RELEASE-p4 > 10.1-STABLE > FreeBSD FBSDG5M1 10.1-RELEASE-p4 FreeBSD 10.1-RELEASE-p4 #1 r277195M: = Mon Jan 26 23:32:28 PST 2015 = root@FBSDG5M1:/usr/obj/usr/home/markmi/src_10_1_releng/sys/GENERIC64vtsc = powerpc >=20 > (My 10.1 kernel variants are for getting evidence about various = PowerMac G5 Quad-Core boot hangups that happen. Also I have both vt and = sc included because of the mix of display hardware that I have around to = use. So ps3 is disabled to allow sc.) >=20 > The 10.1-STABLE world build is from -r277483 . >=20 > (My 10.1-RELEASE-p4 kernel build boots as the default kernel fine = --while my 10.1-STABLE kernel build does not-- both built via the same = r277483 10.1-STABLE world build context. But I can stop the = 10.1-RELEASE-p4 boot during its 10 second wait and then explicitly "boot = kernel10.1S" and that works.) >=20 > /usr/ports/ "Last Changed Rev" was -r378052 (so from today). >=20 powerpc64-xtoolchain-gcc is an external toolchain to cross build base = with recent gcc is that what you want? (in anycase it should not fail :) I'll investigate) Bapt From owner-freebsd-ppc@FreeBSD.ORG Fri Jan 30 07:16:27 2015 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E99B33CA for ; Fri, 30 Jan 2015 07:16:27 +0000 (UTC) Received: from asp.reflexion.net (outbound-242.asp.reflexion.net [69.84.129.242]) (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 A64C1D36 for ; Fri, 30 Jan 2015 07:16:27 +0000 (UTC) Received: (qmail 21838 invoked from network); 30 Jan 2015 07:16:25 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 30 Jan 2015 07:16:25 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.40.0) with SMTP; Fri, 30 Jan 2015 02:16:25 -0500 (EST) Received: (qmail 27798 invoked from network); 30 Jan 2015 07:16:25 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 30 Jan 2015 07:16:25 -0000 X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-67-189-19-145.hsd1.or.comcast.net [67.189.19.145]) by iron2.pdx.net (Postfix) with ESMTPSA id A79B71C43A7; Thu, 29 Jan 2015 23:16:17 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: cmake's ctest throws std::length_error during png build, blocking building (powerpc64, 10.1-STABLE) Date: Thu, 29 Jan 2015 23:16:23 -0800 Message-Id: <9BEAA259-D227-48F7-9170-98DF9810D8C8@dsl-only.net> To: freebsd-ports@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Cc: FreeBSD PowerPC ML X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jan 2015 07:16:28 -0000 Later below I give how I found the issue. But first I show a short way = to reproduce the problem without building a port that uses ctest: root@FBSDG5M1:/usr/home/markmi # ctest --version terminate called after throwing an instance of 'std::length_error' what(): vector::reserve Abort (core dumped) Context basics for the ctest crash: root@FBSDG5M1:/usr/home/markmi # freebsd-version -ku; uname -a 10.1-RELEASE-p4 10.1-STABLE FreeBSD FBSDG5M1 10.1-RELEASE-p4 FreeBSD 10.1-RELEASE-p4 #1 r277195M: = Mon Jan 26 23:32:28 PST 2015 root at = FBSDG5M1:/usr/obj/usr/home/markmi/src_10_1_releng/sys/GENERIC64vtsc = powerpc The 10.1-STABLE world build is from -r277483 . /usr/ports/ "Last Changed Rev" was -r378052 (so recent). root@FBSDG5M1:/usr/home/markmi # more /etc/make.conf WRKDIRPREFIX=3D/usr/obj/portswork WITH_DEBUG=3D MALLOC_PRODUCTION=3D root@FBSDG5M1:/usr/home/markmi # more /etc/src.conf #WITH_DEBUG_FILES=3D #WITHOUT_CLANG=3D root@FBSDG5M1:/usr/home/markmi # cmake --version cmake version 3.1.1 Problem: Later below I give how I found the issue. But first I show a short way = to reproduce the problem without building a port that uses ctest: root@FBSDG5M1:/usr/home/markmi # ctest --version terminate called after throwing an instance of 'std::length_error' what(): vector::reserve Abort (core dumped) =46rom the portmaster -r png I got the following failure, which turns = out to be in cmake's ctest: root@FBSDG5M1:/usr/home/markmi # portmaster -r --no-confirm png ... [100%] Building C object = CMakeFiles/pngstest.dir/contrib/libtests/pngstest.o Linking C executable pngtest [100%] Built target pngtest Linking C executable pngstest [100%] Built target pngstest Linking C executable pngvalid [100%] Built target pngvalid ... Running tests... terminate called after throwing an instance of 'std::length_error' what(): vector::reserve Abort trap (core dumped) *** [test] Error code 134 ... Below is the traceback. It shows a huge vector::reserve size = (#8...::reserve (this=3D0xffffffffffffae08, __n=3D5497010905810357313) = at vector.tcc:72). root@FBSDG5M1:/var/crash # gdb `which ctest` ctest.5708.core ... (gdb) bt #0 0x0000000050d19168 in .__sys_thr_kill () from /lib/libc.so.7 #1 0x0000000050d1907c in .__raise () from /lib/libc.so.7 #2 0x0000000050d17658 in .abort () from /lib/libc.so.7 #3 0x00000000514cbae0 in ._ZN9__gnu_cxx27__verbose_terminate_handlerEv = () from /usr/lib/libsupc++.so.1 #4 0x00000000514d11d8 in ._ZSt14set_unexpectedPFvvE () from = /usr/lib/libsupc++.so.1 #5 0x00000000514d1230 in ._ZSt9terminatev () from = /usr/lib/libsupc++.so.1 #6 0x00000000514d10dc in .__cxa_throw () from /usr/lib/libsupc++.so.1 #7 0x0000000050ab6e54 in ._ZSt20__throw_length_errorPKc () from = /usr/lib/libstdc++.so.6 #8 0x0000000010246528 in = std::vector >*, = std::allocator >*> >::reserve (this=3D0xffffffffffffae08,=20 __n=3D5497010905810357313) at vector.tcc:72 #9 0x0000000010474710 in cmsys::hashtable, std::string, cmsys::hash, = cmsys::hash_select1st, = std::equal_to, std::allocator = >::_M_initialize_buckets (this=3D0xffffffffffffae00, __n=3D100) at = hashtable.hxx:797 #10 0x0000000010474838 in hashtable (this=3D0xffffffffffffae00, __n=3D100,= __hf=3D@0xffffffffffffabb2, __eql=3D@0xffffffffffffabb1,=20 __a=3D@0xffffffffffffabb0) at hashtable.hxx:545 #11 0x000000001047490c in hash_map (this=3D0xffffffffffffae00) at = hash_map.hxx:113 #12 0x00000000104728f8 in cmDefinitions (this=3D0xffffffffffffadf8, = parent=3D0x0) at = /usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.1/Source/cmDefinit= ions.cxx:19 #13 0x000000001020dbcc in cmMakefile (this=3D0x51cb1800) at = /usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.1/Source/cmMakefil= e.cxx:56 #14 0x00000000101efa98 in cmLocalGenerator::SetGlobalGenerator = (this=3D0x51c3f480, gg=3D0xffffffffffffbe38) at = /usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.1/Source/cmLocalGe= nerator.cxx:244 #15 0x00000000101874b0 in cmGlobalGenerator::CreateLocalGenerator = (this=3D0xffffffffffffbe38) at = /usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.1/Source/cmGlobalG= enerator.cxx:1906 #16 0x00000000100224dc in cmCTest::Initialize (this=3D0xffffffffffffcc50,=20= binary_dir=3D0x51c890f8 = "/usr/obj/portswork/usr/ports/graphics/png/work/libpng-1.6.16", = command=3D0x0) at = /usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.1/Source/cmCTest.c= xx:511 #17 0x000000001002c704 in cmCTest::Run (this=3D0xffffffffffffcc50, = args=3D@0xffffffffffffc880, output=3D0xffffffffffffc898) at = /usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.1/Source/cmCTest.c= xx:2474 #18 0x0000000010010c10 in main (argc=3D2, argv=3D0x51c1a040) at = /usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.1/Source/ctest.cxx= :192 #19 0x000000001000fc8c in ._start () #20 0x000000005074c770 in .text () from /libexec/ld-elf.so.1 More context: $ freebsd-version -ku; uname -a 10.1-RELEASE-p4 10.1-STABLE FreeBSD FBSDG5M1 10.1-RELEASE-p4 FreeBSD 10.1-RELEASE-p4 #1 r277195M: = Mon Jan 26 23:32:28 PST 2015 root at = FBSDG5M1:/usr/obj/usr/home/markmi/src_10_1_releng/sys/GENERIC64vtsc = powerpc For the buildworld context: $ svnlite info /usr/src Path: /usr/src 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: 277483 Node Kind: directory Schedule: normal Last Changed Author: smh Last Changed Rev: 277483 Last Changed Date: 2015-01-21 01:45:48 -0800 (Wed, 21 Jan 2015) For the ports: $ svnlite info /usr/ports Path: /usr/ports 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: 378053 Node Kind: directory Schedule: normal Last Changed Author: danilo Last Changed Rev: 378052 Last Changed Date: 2015-01-28 01:33:23 -0800 (Wed, 28 Jan 2015) For the kernel context (not so relevant here but for completeness): $ svnlite info ~markmi/src_10_1_releng/ Path: /home/markmi/src_10_1_releng Working Copy Root Path: /home/markmi/src_10_1_releng URL: https://svn0.us-west.freebsd.org/base/releng/10.1 Relative URL: ^/releng/10.1 Repository Root: https://svn0.us-west.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 277195 Node Kind: directory Schedule: normal Last Changed Author: delphij Last Changed Rev: 277195 Last Changed Date: 2015-01-14 13:27:46 -0800 (Wed, 14 Jan 2015) $ svnlite status ~markmi/src_10_1_releng/ M /home/markmi/src_10_1_releng/sys/ddb/db_main.c M /home/markmi/src_10_1_releng/sys/ddb/db_script.c M /home/markmi/src_10_1_releng/sys/powerpc/ofw/ofw_machdep.c M /home/markmi/src_10_1_releng/sys/powerpc/ofw/ofwcall64.S M = /home/markmi/src_10_1_releng/sys/powerpc/powermac/powermac_thermal.c =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@FreeBSD.ORG Sat Jan 31 19:51:11 2015 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ADEF9286 for ; Sat, 31 Jan 2015 19:51:11 +0000 (UTC) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (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 7CA87352 for ; Sat, 31 Jan 2015 19:51:11 +0000 (UTC) Received: from zeppelin.tachypleus.net (polaris.tachypleus.net [75.101.50.44]) (authenticated bits=0) by d.mail.sonic.net (8.15.1/8.14.9) with ESMTPSA id t0VJp4V8013588 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sat, 31 Jan 2015 11:51:04 -0800 Message-ID: <54CD3228.3090702@freebsd.org> Date: Sat, 31 Jan 2015 11:51:04 -0800 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: FreeBSD PowerPC ML Subject: HEADS UP: powerpc64 kernel format change Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVa8LSeXB0yV4N7zKPs6NqvRxWqtBZrig/a/46mwmUutRvd86gYHLHnr0uJXAapiZnjKvZkQt5bNKVLZ1jrVTBL/RiAltA0SE1E= X-Sonic-ID: C;qEJ2fYKp5BGuQ2S47jkJAQ== M;9JzAfYKp5BGuQ2S47jkJAQ== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jan 2015 19:51:11 -0000 As of r277990, the powerpc64 kernel in 11-CURRENT is now a different executable format (PIE). If you update past this revision, you *must* make sure that you update loader(8) (through updating world) *before* you reboot with a new kernel. If you do not this, your machine will not boot (although you should be able to recover by booting kernel.old from the loader prompt). -Nathan