Date: Wed, 28 Nov 2018 11:30:13 -0800 From: Mark Millard <marklmi@yahoo.com> To: Dennis Clarke <dclarke@blastwave.org> Cc: FreeBSD PowerPC ML <freebsd-ppc@freebsd.org> Subject: Re: revision 341006 quite unusable Message-ID: <554F1239-57F9-462D-918D-6E1FD8ABF9D6@yahoo.com> In-Reply-To: <70945861-107c-b271-93fe-110127d90ba4@blastwave.org> References: <62bd5352-6eb5-ea4c-fd5b-fd4d1a35186b@blastwave.org> <7534F42F-5BFA-4C94-B387-A42F10B5B389@yahoo.com> <0a223db3-8c88-faa9-5cfe-983ada996d4e@blastwave.org> <F33F6393-8B42-46B7-96C6-66D9C39FFA2F@yahoo.com> <70945861-107c-b271-93fe-110127d90ba4@blastwave.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2018-Nov-28, at 07:33, Dennis Clarke <dclarke at blastwave.org> = wrote: > On 11/27/18 7:09 PM, Mark Millard wrote: >> On 2018-Nov-27, at 11:47, Dennis Clarke <dclarke@blastwave.org> = wrote: >>> On 11/27/18 2:28 PM, Mark Millard wrote: >>>> On 2018-Nov-27, at 01:26, Dennis Clarke <dclarke at blastwave.org> = wrote: >>>>> So I did a checkout of revision 341006 and without any changes to = make.conf and a trivial "make buildkernel" followed by the requisite >>>>> "make installkernel" I get a machine with a black screen and = entirely >>>>> quite a warm brick. Loud fans. >>>> Before buildkernel one of the following is needed: >>>> make kernel-toolchain >>>> or: >>>> make buildworld >=20 > did that ... it seems to "install" not much of anything. Neither target installs. kernel-toolchain just puts enough stuff in place to allow a later buildkernel. buildworld, by constrast, includes getting the build infrastructure in place and building everything else except the kernel. Folks working on the kernel do not normally need for the kernel-toolchain to be repeated: that part is typically not what they are changing. So update text, buildkernel, installkernel, boot, tends to be the repetive structure once initialized. One can build once and install in many places without going back through the build step, many times. There is installkernel and installworld for installation. There is the kernel target that does the sequence buildkernel installkernel automatically. >>>> =46rom the comments at the beginning of /usr/src/Makfile : >>>> # buildworld - Rebuild *everything*, including glue to = help do >>>> # upgrades. >>>> . . . >>>> # kernel-toolchain - Builds the subset of world necessary to = build a kernel >>>=20 >>> so .. which comes first ? Or is this an either or situation or do = both? >> Note the word "subset". >=20 > I don't want a "subset". I am fine with building the whole show. There is a big difference in time to build (for from scratch) between the two. Let your time preferences vs. other priorities be your guide if you want to build things that are not used to build or install the kernel but would be involved in a installworld . Repeating buildworld when nothing has changed also takes longer than buildkernel for such a context. >> buildworld generally does more than necessary for kernel work. >=20 > Great! Let's do that. >=20 >> kernel-toolchain does closer to just what is necessary for >> kernel work. >=20 > May as well build everything. >=20 >> There have been times/contexts in which kernel-toolchain was >> broken and buildworld was effectively required for a specific >> context. I've had some history of running into this based on >> a missing header, and so a failed compile. buildworld supplied >> the header in question. But such has not been common. >=20 > Well given that I am trying to build everything then it isn't a = problem. >=20 > The problem is the docs are ... not very helpful. >=20 > People have suggested to me that make buildworld should NOT be = followed by make kernel but make buildkernel : >=20 > https://svnweb.freebsd.org/base/head/UPDATING?view=3Dmarkup#l1770 That it does not use the shorter sequence of "make kernel . . ." does not not mean that the shorter sequence is invalid. Personally I normally do buildkernel and installkernel separately. In part because I build multiple contexts before installing any of them (when I have multiple to build, anyway). I do that because if any of the contexts have build problems, I tend to try to deal with getting all the builds to work first. > The "handbook" is just plain wrong. Where? > No wonder I am going in circles here. Looks like you may be reading to much into some valid examples, as though the example was the unique-valid alternative. >>>> You did not mention /etc/src.conf ( only /etc/make.conf ). My >>>> memory is that those files do not exist by default: even to be >>>> empty they have to be created. >>>=20 >>> Right ... only /etc/make.conf exists and it was just a "touch >>> /etc/make.conf" and nothing else. I really want CFLAGS set as -O0 = and >>> -g and perhaps a few other options to allow debug to be easy. = However >>> for now getting a working compile is step zero. >>>=20 >>>> -r341006 is from head/ ( not stable/ nor releng/ ) in >>>> https://svnweb.freebsd.org/base/ . I'm not sure if this >>>> was intended or not. >>>> (I am currently without access to the FreeBSD environments.) >>>=20 >>> What? How is that possible? Perhaps you are way out on the road >>> somewhere and I thank you for the reply. I felt like I was flailing >>> in the dark here and that is a good description. >> In this case it should be just fairly briefly that I'm without >> access. But there are times when I'm without access for months at >> a time for at least some TARGET_ARCH's compared to my usual >> set of them. >=20 > I have half a dozen PowerMac type units kicking around in a warehouse. > Must be a way to get those moving. However a Power9 server is really > what is needed and all the IBM units that I looked at were in the $10k > zone of cost. Sort of a tough pill to swallow. >=20 >>> I may boot the RC2 DVD and then run dd if=3D/dev/zero = of=3D/dev/diskname >>> and wipe out the first block of cylinders on the disk. Then try a >>> reinstall. I am baffled why the DVD boots fine and I get four = processors >>> online and the installed on disk image does not. That should be = quite >>> impossible. >> For all we know the VM_MAX_KERNEL_ADDRESS value issue could be >> exposing a memory layout dependency that should not be present. >=20 > I don't know. The commits that seem to have happened between RC1 and = RC2 look to be : >=20 > = https://v4.freshbsd.org/search?q=3Dcommit_date%3A%5B2018-11-16+2018-11-23%= 5D&project%5B%5D=3Dfreebsd&repository%5B%5D=3Dsrc&branches%5B%5D=3Dreleng%= 2F12.0&sort=3Dcommit_date_asc >=20 > Somewhere in there ... something went wrong for this machine I have = here.I could revert backwards to RC1 and then build from there forwards. I first saw the problem before RC1. And I've tested a bunch of kernel versions in my context. You are presuming that older than RC1 was generally working. The problem has been observed in various contexts ever since Justin's check in to CURRENT as I understand --but none before as I understand. I did the bisection that found the breaking point for my context so I've tried a bunch of versions, both before and after the breaking point that I found. When I did the bisection I installed officially built kernels from: https://artifact.ci.freebsd.org/ Also: I'm not the only one to have seen that breaking point, so the context is more general than just my context. Just because RC1 happened to side step the problem in your context does not mean that the text of post-RC1 source code updates=20 necessarily contain the problem text. Note: I continued with head instead of following 12. So I've not tried 12.0-RC1. >>> I may try again wwith an SSD but those are giving no advantage at = all. >>> Even older Patriot SATA 1 compliant 1.5Gbps SSD's are really no = better >>> than a spinning disk. >> An SSD with the same scale of seek time as spinning media --or more >> accurately having an overall latency reaching the same scale as >> spinning media? No improvement to the number of random, small = transfers >> per unit time? Wow. >=20 > I tested a new Samsung and an older SSD and there was zero benefit. >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?554F1239-57F9-462D-918D-6E1FD8ABF9D6>