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"
