Note: Fix committed to main for PPC32 SMP

[Mark Millard]

On 2021-Mar-6, at 13:55, Brandon Bergren <bdragon at FreeBSD.org> wrote:

> I finally figured out what was going on with the APs on 32 bit SMP.
> 
> Turns out the APs didn't have r30 initialized, so PLT calls wouldn't work. So when the pmap functions were converted to ifunc in r361544, the APs were unable to call pmap_cpu_bootstrap() from the trap handler code.
> 
> See bad9fa56620eb82395c5ab66d300e91a0222dde2 for the fix.
> 
> Since my dual processor G4 is now working, I can finally make some progress on the timebase handling code.

I did my builds of that version and for the non-debug
32-bit powerpc FreeBSD :

A) The 2-socket/1-core-each G4 boots, has both CPUs in use,
   and USB keyboard input and the like are working. Thanks
   for the update.

B) The 2-socket/1-core-each G5 still hangs extremely early
   when I attempt booting with the 32-bit powerpc media
   that boots the G4 2-socket/1-core-each just fine.

Both of those are probably the expected results at this
point.

I have not tested for the "kernel gradually zeros
user-process memory" problem but I've seen no indication
of any further attempt at improving that beyond the
patches that I was previously given and I'm already running.
(With these patches, a debug kernel notices some of what is
not being done and panics. I'd have to unwind from having
the patches to usefully run a debug kernel on the G4's.)

If I am to test any attempted timebase handling, I'll have
to unwind my code that only tries to get the timebases
close enough to avoid the problem, using a technique that
is not platform specific but not as accurate either. (If
the 32-bit code ever does support booting and operating
multi-cpu G5s again, it would get back into this issue,
just like the powerpc64 code for PowerMacs needs to.)

Thanks again.

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