Date: Wed, 28 Nov 2018 10:33:02 -0500 From: Dennis Clarke <dclarke@blastwave.org> To: Mark Millard <marklmi@yahoo.com> Cc: FreeBSD PowerPC ML <freebsd-ppc@freebsd.org> Subject: Re: revision 341006 quite unusable Message-ID: <70945861-107c-b271-93fe-110127d90ba4@blastwave.org> In-Reply-To: <F33F6393-8B42-46B7-96C6-66D9C39FFA2F@yahoo.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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 did that ... it seems to "install" not much of anything. >>> From 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 >> >> so .. which comes first ? Or is this an either or situation or do both? > > Note the word "subset". I don't want a "subset". I am fine with building the whole show. > buildworld generally does more than necessary for kernel work. Great! Let's do that. > kernel-toolchain does closer to just what is necessary for > kernel work. May as well build everything. > 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. Well given that I am trying to build everything then it isn't a problem. The problem is the docs are ... not very helpful. People have suggested to me that make buildworld should NOT be followed by make kernel but make buildkernel : https://svnweb.freebsd.org/base/head/UPDATING?view=markup#l1770 The "handbook" is just plain wrong. No wonder I am going in circles here. >>> 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. >> >> 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. >> >>> -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.) >> >> 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. 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. > >> I may boot the RC2 DVD and then run dd if=/dev/zero of=/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. > I don't know. The commits that seem to have happened between RC1 and RC2 look to be : https://v4.freshbsd.org/search?q=commit_date%3A%5B2018-11-16+2018-11-23%5D&project%5B%5D=freebsd&repository%5B%5D=src&branches%5B%5D=releng%2F12.0&sort=commit_date_asc 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 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. I tested a new Samsung and an older SSD and there was zero benefit. Dennis
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?70945861-107c-b271-93fe-110127d90ba4>