Re: r356776 breaks kernel for powerpc64 users

2020-01-27 Thread Piotr Kubaj
No, it's ok now. I didn't report it earlier, because I wasn't sure which 
revision fixed it and jeff didn't reply. 

On 20-01-26 16:27:35, 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.
> > 
> > 
> > @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 .
> 
> 
> ===
> Mark Millard
> marklmi at yahoo.com
> ( dsl-only.net went
> away in early 2018-Mar)
> 


signature.asc
Description: PGP signature


Re: r356776 breaks kernel for powerpc64 users

2020-01-26 Thread Mark Millard
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.
> >>
> >>
> >> @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)

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: r356776 breaks kernel for powerpc64 users

2020-01-26 Thread Dennis Clarke

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.


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


--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: r356776 breaks kernel for powerpc64 users

2020-01-26 Thread Mark Millard
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.
> 
> 
> @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 .


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

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


r356776 breaks kernel for powerpc64 users

2020-01-16 Thread Piotr Kubaj
Hi,

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.

@jeff
Since you commited this patch, can you fix this issue or revert this commit?


Thanks,
Piotr Kubaj.


signature.asc
Description: PGP signature