revision 341006 quite unusable

Mark Millard marklmi at
Wed Nov 28 19:30:18 UTC 2018

On 2018-Nov-28, at 07:33, Dennis Clarke <dclarke at> wrote:

> On 11/27/18 7:09 PM, Mark Millard wrote:
>> On 2018-Nov-27, at 11:47, Dennis Clarke <dclarke at> wrote:
>>> On 11/27/18 2:28 PM, Mark Millard wrote:
>>>> On 2018-Nov-27, at 01:26, Dennis Clarke <dclarke at> 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.

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.

>>>> 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.

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.
> 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 :

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.


> 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.
>>> 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
>>>> . 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 :
> 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:

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 
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.
> I tested a new Samsung and an older SSD and there was zero benefit.

Mark Millard
marklmi at
( went
away in early 2018-Mar)

More information about the freebsd-ppc mailing list