revision 341104 quite unusable

Wed Nov 28 22:50:35 UTC 2018

On 11/28/18 2:30 PM, Mark Millard wrote:
> On 2018-Nov-28, at 07:33, Dennis Clarke <dclarke at blastwave.org> wrote:
>> On 11/27/18 7:09 PM, Mark Millard wrote:
>>> 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

Actually 341104 this morning :

root at eris:~ # cd /usr/src
root at eris:/usr/src #
root at eris:/usr/src # svnlite checkout http://svn.freebsd.org/base/head
A    head/sys
A    head/sys/powerpc
A    head/sys/powerpc/booke
A    head/sys/powerpc/include/atomic.h
...
A    head/.arcconfig
  U   head
Checked out revision 341104.
root at eris:/usr/src #

>>>>> Before buildkernel one of the following is needed:
>>>>> make kernel-toolchain
>>>>> or:
>>>>> make buildworld

I went with :

root at eris:/usr/src # cd head
root at eris:/usr/src/head # /usr/bin/time -p make buildworld | tee 
../rev_341104_buildworld.log
[Creating objdir /usr/obj/usr/src/head/powerpc.powerpc64...]
--------------------------------------------------------------
 >>> World build started on Wed Nov 28 05:25:54 UTC 2018
--------------------------------------------------------------

--------------------------------------------------------------
 >>> Rebuilding the temporary build tree
--------------------------------------------------------------
rm -rf /usr/obj/usr/src/head/powerpc.powerpc64/tmp
cd /usr/src/head/tools/build;  make DIRPRFX=tools/build/ 
DESTDIR=/usr/obj/usr/src/head/powerpc.powerpc64/tmp/legacy installdirs
.
. * * *  make coffee and maybe go paint a suspension bridge  * * *
.
cc -DCOMPAT_32BIT -mcpu=powerpc -m32 
-L/usr/obj/usr/src/head/powerpc.powerpc64/obj-lib32/tmp/usr/lib32 
--sysroot=/usr/obj/usr/src/head/powerpc.powerpc64/obj-lib32/tmp 
-B/usr/obj/usr/src/head/powerpc.powerpc64/tmp/usr/bin 
-B/usr/obj/usr/src/head/powerpc.powerpc64/obj-lib32/tmp/usr/lib32 -O2 
-pipe -g -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror 
-Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes 
-Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual 
-Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align 
-Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls 
-Wold-style-definition -Wno-pointer-sign   -o ldd32.full ldd.o
objcopy --only-keep-debug ldd32.full ldd32.debug
objcopy --strip-debug --add-gnu-debuglink=ldd32.debug  ldd32.full ldd32

--------------------------------------------------------------
 >>> World build completed on Wed Nov 28 13:02:33 UTC 2018
--------------------------------------------------------------
real 27402.89
user 12559.89
sys 13336.51

root at eris:/usr/src/head #

root at eris:/usr/src/head # /usr/bin/time -p make buildkernel | tee 
../rev_341104_buildkernel.log
.
.  * * *  refill coffee cup * * *
.
.
objcopy --only-keep-debug zlib.ko.full zlib.ko.debug
objcopy --strip-debug --add-gnu-debuglink=zlib.ko.debug  zlib.ko.full 
zlib.ko
--------------------------------------------------------------
 >>> Kernel build for GENERIC64 completed on Wed Nov 28 17:14:42 UTC 2018
--------------------------------------------------------------
real 4840.48
user 2516.73
sys 2015.42
root at eris:/usr/src/head #

Lovely.

> Neither target installs. kernel-toolchain just puts enough

Makes sense to me.

So I then did ye "make installkernel" and felt a shutdown was required.
Which then resulted in the usual poweron, wait for open firmware and
interrupt the boot process to set kern.smp.disabled=1 and also the
then utter "noot -s" and get a black screen and warm brick with fans
roaring.

I try to limit my warm brick creation to once a day plus vitamines.

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

Since I have never seen it work even once I was going to take
no chances and just checkout the whole src.

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

Well, I have a warm brick here. So I booted from the RC2 dvd image and
with a shell I guess I will mount /dev/ada0s3 and then move around the
kernel.old stuff.

I am still baffled ( correct word ) that the kernel and tools on the RC2
bootable dvd seem fine with four cpu cores. Then actual installed system
image that results just hangs the boot process without kern.smp.disabled
being set.

That sort of points to a module somewhere. My guess.

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

coffee supply?

Not a problem. As Paul Mather was very cool to point out this old ppc64
PowerMac G5 is a tier 2 type platform with tier whenever type real world
expectations.  I think a Power9 server is really needed but one step at
a time here.

I am looking here :

>> https://svnweb.freebsd.org/base/head/UPDATING?view=markup#l1770
> 
> That it does not use the shorter sequence of "make kernel . . ." does
> not not mean that the shorter sequence is invalid.

I get different suggestions from different people. Given that I have yet
to see anything work I am waiting for that eureka moment when a newly
compiled kernel boots at all. Single user mode or whatever I can get.

> 
> Personally I normally do buildkernel and installkernel separately.

Makes sense.

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

Let's not go there.  The ppc64 world is just sligtly different and needs
its own docs and I'll be happy to write stuff *after* I get a build that
can boot once.

> I first saw the problem before RC1. And I've tested a bunch
> of kernel versions in my context.

Right.  A few weeks ago somewhere in beta3 perhaps?  However RC1 was
just fine.

> You are presuming that older than RC1 was generally working. 

No no .. I had RC1 running fine for days and even dragged in my own
software projects and started compiling and running tests. With gmp and
mpfr I get exactly perfect results that match my Solaris systems and
Linux systems. I think RC1 was working well enough for the limited tests
that I was running.

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

I was not aware of that site.  Well now .. how does that help .. let
me look :

https://artifact.ci.freebsd.org/snapshot/head/r341104/powerpc/powerpc64/

OKay ... I will watch there.  Good to know.  Thank you.

> Also: I'm not the only one to have seen that breaking point, so
> the context is more general than just my context.

I still have to go with the idea that a module is the issue and not the
kernel. Some other item in the mixture here is the issue.  Has to be.  I
am running the RC2 bootable dvd now. All cpu cores are available per :

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233579

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

OKay .. makes sense to me.

> 
> Note: I continued with head instead of following 12. So I've
> not tried 12.0-RC1.
> 

OKay well, as I was saying at lung exhaustive length, I have yet to see
anything build and boot other than the RC2 dvd.  At least in a natural
way.

I will keep plugging away here.

Dennis Clarke