From owner-freebsd-ppc@freebsd.org Wed Nov 28 15:33:12 2018 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 909FA11579B4 for ; Wed, 28 Nov 2018 15:33:12 +0000 (UTC) (envelope-from dclarke@blastwave.org) Received: from atl4mhob09.registeredsite.com (atl4mhob09.registeredsite.com [209.17.115.47]) by mx1.freebsd.org (Postfix) with ESMTP id 904EA790FA for ; Wed, 28 Nov 2018 15:33:11 +0000 (UTC) (envelope-from dclarke@blastwave.org) Received: from mailpod.hostingplatform.com (atl4qobmail02pod2.registeredsite.com [10.30.77.36]) by atl4mhob09.registeredsite.com (8.14.4/8.14.4) with ESMTP id wASFX3dC018146 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Wed, 28 Nov 2018 10:33:03 -0500 Received: (qmail 23845 invoked by uid 0); 28 Nov 2018 15:33:03 -0000 X-TCPREMOTEIP: 174.118.245.214 X-Authenticated-UID: dclarke@blastwave.org Received: from unknown (HELO ?172.16.35.3?) (dclarke@blastwave.org@174.118.245.214) by 0 with ESMTPA; 28 Nov 2018 15:33:03 -0000 Subject: Re: revision 341006 quite unusable To: Mark Millard Cc: FreeBSD PowerPC ML References: <62bd5352-6eb5-ea4c-fd5b-fd4d1a35186b@blastwave.org> <7534F42F-5BFA-4C94-B387-A42F10B5B389@yahoo.com> <0a223db3-8c88-faa9-5cfe-983ada996d4e@blastwave.org> From: Dennis Clarke Message-ID: <70945861-107c-b271-93fe-110127d90ba4@blastwave.org> Date: Wed, 28 Nov 2018 10:33:02 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:64.0) Gecko/20100101 Thunderbird/64.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 904EA790FA X-Spamd-Result: default: False [0.46 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-0.54)[-0.544,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-ppc@freebsd.org]; DMARC_NA(0.00)[blastwave.org]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.05)[0.050,0]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: mx1.netsolmail.net]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[47.115.17.209.list.dnswl.org : 127.0.5.0]; NEURAL_HAM_SHORT(-0.02)[-0.016,0]; R_SPF_NA(0.00)[]; FREEMAIL_TO(0.00)[yahoo.com]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; IP_SCORE(-0.02)[country: US(-0.09)]; ASN(0.00)[asn:19871, ipnet:209.17.112.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Server: mx1.freebsd.org X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2018 15:33:12 -0000 On 11/27/18 7:09 PM, Mark Millard wrote: > > > On 2018-Nov-27, at 11:47, Dennis Clarke wrote: > >> On 11/27/18 2:28 PM, Mark Millard wrote: >>> On 2018-Nov-27, at 01:26, Dennis Clarke 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