From owner-freebsd-ppc@freebsd.org Wed Nov 28 19:30:18 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 BEDD8113B482 for ; Wed, 28 Nov 2018 19:30:17 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-32.consmr.mail.ne1.yahoo.com (sonic301-32.consmr.mail.ne1.yahoo.com [66.163.184.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E18DE85A15 for ; Wed, 28 Nov 2018 19:30:16 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: 3TQ6sXMVM1mW52SoSmAV_o26G1eFfcfdjn8_0HtC.XzKdjKDXFdYwYZLeiQEhOb 3tK6LzYgMkAc5UgPRzmAWtN4.1aaKYJeMLY3EBUYoCmYQn0L5xRCwMtE751on7KDiV1p18Vz.aTF jev7TAhPwMdAU5pLoF3d0xo6RWVdNj0Tp190HQgz3gGoWO4kn5qOOrAdLOnOAhUihEM1nR4KTO4F dzu1UALyTtGAsGHvAAynOnriRQo8ueoqVEzfUCQjpF1xHQFngHV42AKccGzRXc2MaTJKAAT9OUaK gwO_.V73uQwyYg1gN6OFmwOtclcB8Vh.rGaZ5vBAnV4.tn6W26PQPLHKGHCnMhqRKbpg1Kaa8XHN LEYc70OayZt16z84i.b879YngI9JcuNFo4sGuN6i2Fk18CetuhAghvg_3OeFHTZSLwLOtdxTHP1C cscniEPEEnv3u4ZQ37LP0FfgiWYfr5GK5SQV3Ri_.2iXQJaysVucOy8tgw1KqNlDnZGVzVTM8daw aTgEjXeFEJtU2bl4gtLlrvaLBfa3fi1d20kJuvexgOuH3jufyjDcdmuTQmeqn9GCulogB86qealh hLE8X2rUas9Aojt6iH_o7LtML4jHbWoSI3uiFrCqQmmM0u0IzedWLpdZxp_deGhRns1YHrU6Q5Mz h6PSk3R_c_iEcVFELt0Uff6OhFqAy1PLk_SCFnUvP3HrxM9jNNdcXW.Kq1xEA2EqlD.xYZJg4KZL 3SrKi2ugOWyX3duoLGvmFX6DrntXk5P5pNYXlIkcrGGfCJvUqLVrE59Xw2xpg7F.FwNJaRfaUtt2 XVG5VJtq2aJ.TjpEJ2oTHITdsK6yLGb4kjqsPpF3adWQsR.lGXIWyAeli02kWJ5GQafzCW.rBAWf bMELExiVbt0wLpeUnmG.lTMod7RYX0ujdjdYYUiK7r3xff4ZtiQL7pyB0tDf8G7ahod2JIf5YVHo nnU5EcKKDzPC4U7XaI0Xp2xsOH50N_eDL7_.1rr50ks3J8ffwuU_SFmQsj0lWUxoodaRvzzUPSK9 IW3tbZ1o9HmLlTF6B34wC3mbmoFJEgSfMcEgY0_0pN6WmgAC3ACfov.b0jQIo Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.ne1.yahoo.com with HTTP; Wed, 28 Nov 2018 19:30:16 +0000 Received: from c-67-170-167-181.hsd1.or.comcast.net (EHLO [192.168.1.109]) ([67.170.167.181]) by smtp407.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID e91c4201d342436fa979742905937eca; Wed, 28 Nov 2018 19:30:14 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) Subject: Re: revision 341006 quite unusable From: Mark Millard In-Reply-To: <70945861-107c-b271-93fe-110127d90ba4@blastwave.org> Date: Wed, 28 Nov 2018 11:30:13 -0800 Cc: FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: <554F1239-57F9-462D-918D-6E1FD8ABF9D6@yahoo.com> References: <62bd5352-6eb5-ea4c-fd5b-fd4d1a35186b@blastwave.org> <7534F42F-5BFA-4C94-B387-A42F10B5B389@yahoo.com> <0a223db3-8c88-faa9-5cfe-983ada996d4e@blastwave.org> <70945861-107c-b271-93fe-110127d90ba4@blastwave.org> To: Dennis Clarke X-Mailer: Apple Mail (2.3445.101.1) X-Rspamd-Queue-Id: E18DE85A15 X-Spamd-Result: default: False [2.60 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MV_CASE(0.50)[]; FREEMAIL_FROM(0.00)[yahoo.com]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MX_GOOD(-0.01)[cached: mta6.am0.yahoodns.net]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36646, ipnet:66.163.184.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.37)[0.367,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(1.61)[ip: (5.52), ipnet: 66.163.184.0/21(1.45), asn: 36646(1.16), country: US(-0.09)]; NEURAL_SPAM_MEDIUM(0.60)[0.598,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.53)[0.535,0]; RCVD_IN_DNSWL_NONE(0.00)[201.184.163.66.list.dnswl.org : 127.0.5.0]; RWL_MAILSPIKE_POSSIBLE(0.00)[201.184.163.66.rep.mailspike.net : 127.0.0.17] 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 19:30:18 -0000 On 2018-Nov-28, at 07:33, Dennis Clarke = wrote: > 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 >=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)