Re: r356776 breaks kernel for powerpc64 users

Dennis Clarke dclarke at blastwave.org wrote on
Mon Jan 27 02:25:15 UTC 2020 :

> On 2020-01-26 19:27, Mark Millard wrote:
> > Piotr Kubaj listy at anongoth.pl wrote on
> > Thu Jan 16 19:56:11 UTC 2020 :
> > 
> >> revision 356776 breaks booting for powerpc64 users. It reportedly works fine on POWER8, but I get kernel panic on POWER9 (Talos II) right after the usual warning: WITNESS enabled. Kernel panic is uploaded to https://pastebin.com/s8ZaUNS2.
> >>
> >>
> >> _at_jeff
> >> Since you commited this patch, can you fix this issue or revert this commit?
> >>
> > 
> > Is this still a problem for powerpc64? I've not seen
> > anything looking like a direct response or like a
> > status update for this.
> > 
> > I do see arm report(s) of problems that they also
> > attributed to head -r356776 . But I've no clue how
> > good the evidence is generally. An example message
> > is:
> > 
> > https://lists.freebsd.org/pipermail/freebsd-arm/2020-January/021069.html
> > 
> > But one part of that is for specifically for going
> > from -r356767 to the next check-in to head: -r356776 .
> > That problem likely has good evidence for the
> > attribution to -r356776 .
> > 
> 
> I will give current a try and report back. However I am hesitant to do 
> so as I have a working G5 right now.
> 
> For science ... I will do the experiment.

If Piotr has a context that fairly reliably gives the problem
still, you might want to wait until it starts working. Especially
if you can not keep a bootable copy of your working environment.
I've not heard one way or the other for any PowerMacs. Piotr
indicated some POWER8 contexts did not get the problem that he
got on POWER9.

Also, unfortunately, head -r356899 eliminated the old binutils
as program but powerpc64 can still require it for an (empty!)
crtsavres.s assembly. powerpc64 probably needs to be changed
to avoid using an external assembler for anything, even
indirectly via system-clang reaching into /usr/local/ if it
does so. (Otherwise an external toolchain is still required.)
Of course, if one is not building from source, this is not
an issue.

Another issue is that the "epoch" usage changes seem to have
lead to a fair number of crash problems as the various places
gradually are updated to use it the new way but do not fully
work prior to their updates. (It is just an impression of what
I've read but not dealt with: I might have summarized
incorrectly.)

These and -r536776 related material have overlapping time
frames, so it may be things are odd until all 3 areas have
been taken care of sufficiently.

I'm still holding at head -r356426 as the base version for
my activities.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)