revision 341006 quite unusable
Mark Millard
marklmi at yahoo.com
Wed Nov 28 00:10:04 UTC 2018
On 2018-Nov-27, at 11:47, Dennis Clarke <dclarke at 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
>
> Ah well ... I did go back and try a "make buildworld" and in fact I did it this way :
>
> root at eris:/usr/src #
> root at eris:/usr/src # /usr/bin/time -p make buildworld | tee ../rev341008_buildworld.log
> --------------------------------------------------------------
> >>> World build started on Tue Nov 27 09:27:45 UTC 2018
> --------------------------------------------------------------
>
> --------------------------------------------------------------
> >>> Rebuilding the temporary build tree
> --------------------------------------------------------------
> rm -rf /usr/obj/usr/src/powerpc.powerpc64/tmp
> .
> .
> .
>
> objcopy --only-keep-debug ldd32.full ldd32.debug
> objcopy --strip-debug --add-gnu-debuglink=ldd32.debug ldd32.full ldd32
>
> --------------------------------------------------------------
> >>> World build completed on Tue Nov 27 16:48:18 UTC 2018
> --------------------------------------------------------------
> real 26436.93
> user 12547.80
> sys 13005.84
> root at eris:/usr/src #
>
> So that is offensively slow but a gcc bootstrap is far worse. So no
> big deal .. I can handle it.
>
>> 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".
buildworld generally does more than necessary for kernel work.
kernel-toolchain does closer to just what is necessary for
kernel work.
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.
>> 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 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 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.
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
More information about the freebsd-ppc
mailing list