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>
index | next in thread | previous in thread | raw e-mail
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: > >> On 2017-Jul-4, at 3:52 PM, Alan Braslau <braslau.list@comcast.net> >> wrote: >> >>> . . . >> >> There are two revisions for svn. If you explicitly use >> update -r?????? the two will be equal, for example: >> >> # svnlite info /usr/src | grep "Re[plv]" >> 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 >> >> But if you just grab the most current without >> specifying then the "Last Changed Rev" number >> is what you want to reference. >> >> 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. >> >>> (am I misusing svn?) >>> >>> Also, I thought that I specified powerpc64. >> >> I agree that I likely should have taken >> "freebsd 11.0 powerpc64" to mean: >> >> TARGET_ARCH=powerpc64 >> >> 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=powerpc >> recently has had extra problems that did not >> show up for TARGET_ARCH=powerpc64 .) >> >>> 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). >> >> I've never used PORTS_MODULES or the like >> so I'm unsure of the details for avoiding >> compatibility issues. >> >> >> === >> Mark Millard >> markmi at dsl-only.net >> > > Thank you for the explanations. > I had simply typed: > > mv /usr/src /usr/src.bak > svn co https://svn.freebsd.org/base/releng/11.0 /usr/src > > I may have done an > > svn up > > 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. === Mark Millard markmi at dsl-only.nethelp
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?126985AE-747B-4CC9-8460-C53BFE6E3CEC>