Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 6 Mar 2021 19:58:01 -0800
From:      Mark Millard <marklmi@yahoo.com>
To:        Brandon Bergren <bdragon@FreeBSD.org>
Cc:        FreeBSD PowerPC ML <freebsd-ppc@freebsd.org>
Subject:   Re: Note: Fix committed to main for PPC32 SMP
Message-ID:  <7082DB3B-FA63-4D08-91CB-7B4A4FA1501A@yahoo.com>
In-Reply-To: <95e4ea92-128b-4765-bdb1-4726b2573b4c@www.fastmail.com>
References:  <95e4ea92-128b-4765-bdb1-4726b2573b4c@www.fastmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help


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.
>=20
> 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.
>=20
> See bad9fa56620eb82395c5ab66d300e91a0222dde2 for the fix.
>=20
> 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.

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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7082DB3B-FA63-4D08-91CB-7B4A4FA1501A>