From owner-freebsd-ppc@freebsd.org Wed Jul 5 00:33:40 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 37A56D9E42C for ; Wed, 5 Jul 2017 00:33:40 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-18.reflexion.net [208.70.210.18]) (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 EC330683BC for ; Wed, 5 Jul 2017 00:33:39 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 19072 invoked from network); 5 Jul 2017 00:33:38 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 5 Jul 2017 00:33:38 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.1) with SMTP; Tue, 04 Jul 2017 20:33:38 -0400 (EDT) Received: (qmail 19537 invoked from network); 5 Jul 2017 00:33:38 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 5 Jul 2017 00:33:38 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 64A25EC85D5; Tue, 4 Jul 2017 17:33:37 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: powerpc64 update from source kernel panic (11.0) From: Mark Millard In-Reply-To: <20170704175546.3f006aee@zoo.hsd1.co.comcast.net> Date: Tue, 4 Jul 2017 17:33:36 -0700 Cc: FreeBSD PowerPC ML , Justin Hibbits Content-Transfer-Encoding: quoted-printable Message-Id: <126985AE-747B-4CC9-8460-C53BFE6E3CEC@dsl-only.net> References: <20170704145456.6d8c095e@zoo.hsd1.co.comcast.net> <19637A8C-9C28-42D9-8E3E-E30E998D787A@dsl-only.net> <20170704165249.10d01228@zoo.hsd1.co.comcast.net> <7800C44D-8FD9-480B-8D53-D505F72F082E@dsl-only.net> <20170704175546.3f006aee@zoo.hsd1.co.comcast.net> To: Alan Braslau 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: Wed, 05 Jul 2017 00:33:40 -0000 On 2017-Jul-4, at 4:55 PM, Alan Braslau = wrote: > On Tue, 4 Jul 2017 16:28:14 -0700 > Mark Millard wrote: >=20 >> On 2017-Jul-4, at 3:52 PM, Alan Braslau >> wrote: >>=20 >>> . . . >>=20 >> There are two revisions for svn. If you explicitly use >> update -r?????? the two will be equal, for example: >>=20 >> # svnlite info /usr/src | grep "Re[plv]"=20 >> Relative URL: ^/head >> Repository Root: svn://svn0.us-west.freebsd.org/base >> Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f >> Revision: 320570 >> Last Changed Rev: 320570 >>=20 >> But if you just grab the most current without >> specifying then the "Last Changed Rev" number >> is what you want to reference. >>=20 >> The other number will reflect the global svn >> state across branches and such and so frequently >> will appear more recent than what is actually >> checked out and also possibly pointing into >> the wrong branch. >>=20 >>> (am I misusing svn?) >>>=20 >>> Also, I thought that I specified powerpc64. =20 >>=20 >> I agree that I likely should have taken >> "freebsd 11.0 powerpc64" to mean: >>=20 >> TARGET_ARCH=3Dpowerpc64 >>=20 >> But, with things already being odd, I wanted to >> be sure it was just not the processor-type that >> was being specified. (In head TARGET_ARCH=3Dpowerpc >> recently has had extra problems that did not >> show up for TARGET_ARCH=3Dpowerpc64 .) >>=20 >>> Indeed, the problem seems to be the loading of a kmod that does not >>> get updated until installworld. My fault (or some missing >>> information in the handbook). =20 >>=20 >> I've never used PORTS_MODULES or the like >> so I'm unsure of the details for avoiding >> compatibility issues. >>=20 >>=20 >> =3D=3D=3D >> Mark Millard >> markmi at dsl-only.net >>=20 >=20 > Thank you for the explanations. > I had simply typed: >=20 > mv /usr/src /usr/src.bak > svn co https://svn.freebsd.org/base/releng/11.0 /usr/src >=20 > I may have done an >=20 > svn up >=20 > the next day before buildworld. > (I have never specified revisions, as I have usually used svn on an > entire project repository.) I update via: svnlite update -r?????? /usr/src/ or for ports: svnlite update -r????? /usr/ports/ (The ending "/"s are optional.) I try to monitor enough to pick what I hope will be stable/reliable versions from what I've seen --and that will have specific things of interest. I rarely simply grab the most recent version of the /usr/src/ tree, at least for contexts in which I'm using head. Note that this -r?????? based update does update a whole project directory tree. If I establish a new /usr/src/ tree I use: svnlite co -r?????? . . . /usr/src/ again being specific about which version that I get. But that is just me. > By the way, the handbook does not suggest using "svn up -rXXXXXX" so I > do not know that I did anything unusual. = https://www.freebsd.org/doc/en/articles/committers-guide/subversion-primer= .html does say: 5.3.4. Updating the Tree To update a working copy to either the latest revision, or a specific = revision: % svn update % svn update -r12345 To show local changes and files that are out-of-date do: % svn status --show-updates (This does presume one has cd'd to the top of the directory tree to be updated since they do not list the path on the command lines.) > I still don't get the problem as I am not using any PORTS_MODULES. > I see that /boot/kernel is a directory containing all of its modules, > as is /boot/kernel.old Lack of use of PORTS_MODULES would imply that kernel builds end up with the older, none-updated module being present. I expect that PORTS_MODULES purpose is to keep modules from ports up to date with system builds, being rebuilt based on updated headers and such. But I do not know the details of its use or what else may be required. installkernel, delete-old, and the like do not deal with removing modules that have been removed from the newer system or are otherwise not being installed any more. I periodically do something like: ls -lTt /boot/kernel/ | tail -20 to see if I've got something that is not being updated as expected. (The times are install times here, not build times, so old dates mean "not recently installed".) But I do not add any modules to the defaults or have any from ports. (My context is normally some variant of head since around when clang 3.8 became a project.) > The updated system is running, and I have moved the loading of the > wireless module from /boot/loader.conf to /etc/rc.conf. Maybe this > module is fussy about when it is loaded and perhaps it is not = generally > recommended to load modules via loader.conf. Note that the module > loaded previous to the update of the kernel via loader.conf. Interesting. =3D=3D=3D Mark Millard markmi at dsl-only.net