Date: Tue, 16 Apr 2019 16:42:10 -0500 From: Justin Hibbits <chmeeedalf@gmail.com> To: Mark Millard <marklmi@yahoo.com> Cc: freebsd-ppc <freebsd-ppc@freebsd.org> Subject: Re: head -r344018 powerpc64 variant on Powermac G5 (2 sockets, 2 cores each): [*buffer arena] shows up more . . .? [mpc85xx_smp_timebase_sync problem too] Message-ID: <20190416164210.26827a6d@titan.knownspace> In-Reply-To: <984188AE-93A9-4321-99EC-522C2E0CE9A9@yahoo.com> References: <D9B56EE2-35C7-44A2-9229-D9E4AECAD3E1@yahoo.com> <20190306151914.44ea831c@titan.knownspace> <8668AAF7-9E6A-4278-9D1B-2ECDBD3804AA@yahoo.com> <99AD89F8-0F90-48BE-A060-DA12FD7129E6@yahoo.com> <20190306223611.75c8a87e@titan.knownspace> <984188AE-93A9-4321-99EC-522C2E0CE9A9@yahoo.com>
index | next in thread | previous in thread | raw e-mail
On Tue, 16 Apr 2019 14:26:39 -0700
Mark Millard <marklmi@yahoo.com> wrote:
> [Looks to me like the use and content of mpc85xx_smp_timebase_sync
> have the same type of problems I noted for the proposed powermac
> patch.]
>
...
> >
> > As mentioned, I had only compiled it. Your examination of the code
> > path demonstrates that the patch is insufficient, and would hang at
> > unleash anyway. The sleep/wake logic probably needs to be updated
> > anyway. It was written for a G4 powerbook primarily for the
> > PMU-based cpufreq driver, so some bits might need to be moved
> > around. Orthogonal to this issue, though.
>
> It appears to me that the overall sequence:
>
> platform_smp_timebase_sync(0, 1); // called from
> cpudep_ap_setup . . .
> // The following are from in machdep_ap_bootstrap . . .
> while (ap_letgo == 0)
> __asm __volatile("or 31,31,31");
> __asm __volatile("or 6,6,6");
> . . .
> platform_smp_timebase_sync(ap_timebase, 1);
>
> calls mpc85xx_smp_timebase_sync twice per ap and that the
> 2nd call has tb_ready && mp_ncpus<=cpu_done for each such
> ap, leading to a lack of coordination of the activity that
> 2nd time for each ap:
>
> static void
> mpc85xx_smp_timebase_sync(platform_t plat, u_long tb, int ap)
> {
> static volatile bool tb_ready;
> static volatile int cpu_done;
>
> if (ap) {
> /* APs. Hold off until we get a stable timebase. */
> while (!tb_ready)
> atomic_thread_fence_seq_cst();
> mttb(tb);
> atomic_add_int(&cpu_done, 1);
> while (cpu_done < mp_ncpus)
> atomic_thread_fence_seq_cst();
> } else {
> /* BSP */
> freeze_timebase(rcpm_dev, true);
> tb_ready = true;
> mttb(tb);
> atomic_add_int(&cpu_done, 1);
> while (cpu_done < mp_ncpus)
> atomic_thread_fence_seq_cst();
> freeze_timebase(rcpm_dev, false);
> }
> }
>
Not for mpc85xx. This is call is only in the AIM cpudep_ap_setup, and
really shouldn't be there anyway. The original code to just set the
timebase was there to set it to 0 just as a semi-sane value until the
core got to a stable state. The original code was literally "mttb(0)"
for G4, and a check for hypervisor with mttb(0). Had that been
sufficient, the platform_smp_timebase_sync() would not be a problem to
do the real sync as I had mentioned in my patch before.
The powermac patch that I had provided was derived from this
well-working mpc85xx patch. However, I had neglected to check that the
sync wasn't used elsewhere as well. If the cpudep_ap_setup() use is
removed, then this should work fine.
- Justin
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20190416164210.26827a6d>