Re: revision 341006 quite unusable

On 11/27/18 7:09 PM, Mark Millard wrote:
> 
> 
> 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

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
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ppc
To unsubscribe, send any mail to "[email protected]"