Re: head -r344018 powerpc64 variant on Powermac G5 (2 sockets, 2 cores each): [*buffer arena] shows up more . . .? [mpc85xx_smp_timebase_sync problem too]

Justin Hibbits <[email protected]>
Newsgroups gmane.os.freebsd.devel.ppc
Message-ID <[email protected]>
On Tue, 16 Apr 2019 14:26:39 -0700
Mark Millard <[email protected]> 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
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ppc
To unsubscribe, send any mail to "[email protected]"
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.