Date: Tue, 4 Jul 2017 17:33:36 -0700 From: Mark Millard <markmi@dsl-only.net> To: Alan Braslau <braslau.list@comcast.net> Cc: FreeBSD PowerPC ML <freebsd-ppc@freebsd.org>, Justin Hibbits <jhibbits@FreeBSD.org> Subject: Re: powerpc64 update from source kernel panic (11.0) Message-ID: <126985AE-747B-4CC9-8460-C53BFE6E3CEC@dsl-only.net> In-Reply-To: <20170704175546.3f006aee@zoo.hsd1.co.comcast.net> References: <AFE787D7-EFCB-4265-B2FB-6A4587DAD4FA@dsl-only.net> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2017-Jul-4, at 4:55 PM, Alan Braslau <braslau.list@comcast.net> = wrote: > On Tue, 4 Jul 2017 16:28:14 -0700 > Mark Millard <markmi@dsl-only.net> wrote: >=20 >> On 2017-Jul-4, at 3:52 PM, Alan Braslau <braslau.list@comcast.net> >> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?126985AE-747B-4CC9-8460-C53BFE6E3CEC>