Re: revision 341006 quite unusable

On 2018-Nov-27, at 11:47, Dennis Clarke <[email protected]> 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@eris:/usr/src #
> root@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@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)

_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ppc
To unsubscribe, send any mail to "[email protected]"