svn commit: r221791 - projects/largeSMP/sys/sparc64/include

[Marius Strobl]

On Thu, May 12, 2011 at 04:00:35AM +0200, Attilio Rao wrote:
> 2011/5/11 Marius Strobl <marius at alchemy.franken.de>:
> > On Wed, May 11, 2011 at 11:28:33PM +0200, Attilio Rao wrote:
> >> 2011/5/11 Marius Strobl <marius at freebsd.org>:
> >> > Author: marius
> >> > Date: Wed May 11 21:15:12 2011
> >> > New Revision: 221791
> >> > URL: http://svn.freebsd.org/changeset/base/221791
> >>
> >> Thanks a lot for your commit.
> >> I see you didn't commit yet the mp_machdep part, is that any problem with it?
> >
> > Given that I currently don't understand how the remaining problems
> > I'm seeing with largeSMP actually can happen I'm just using the
> > hack of just changing the 32-bit assembler instructions into 64-bit
> > ones assuming that _NCPUWORDS is 1 for now as I described earlier.
> > So the properly converted mp_exception.S isn't really tested so far,
> > which is why I haven't commited it, yet, if that's what you meant
> > by mp_machdep part.
> 
> Yes, sorry.
> 
> Could you please explain what the code you are trying to change does?
> 

It's the IPI_DONE macro which clears cpuid/cpumask in the first members
of the IPI args structures (ita_mask etc) once a receiving CPU has
handled the cross-call. Given that it survives the first dozens of IPIs
just like the hacked version I've committed it in r221805. Note that
this needs r221750 to be MFC'ed in order to compile.

The only thing which I currently can think of causing the courruption
of pc_other_cpus is that I'm testing with a non-largeSMP userland. Is
there something which fiddles with the pcpu stuff from userland? If so
we have a big problem with the upgrade path ...
On the other hand given that it's always pc_cpuid which get's added to
pc_other_cpus this doesn't really look like a random corruption caused
by an ABI breakage or a wrong offset used etc.

Marius