Date: Thu, 12 May 2011 11:41:52 +0200 From: Marius Strobl <marius@alchemy.franken.de> To: Attilio Rao <attilio@freebsd.org> Cc: svn-src-projects@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r221791 - projects/largeSMP/sys/sparc64/include Message-ID: <20110512094152.GV92688@alchemy.franken.de> In-Reply-To: <BANLkTi=weyxZDhETjki28kg_a8SadprXSw@mail.gmail.com> References: <201105112115.p4BLFCGW006442@svn.freebsd.org> <BANLkTimGEiVc8Ouo0VC9zmo-q2U5sYJJMg@mail.gmail.com> <20110511215019.GU92688@alchemy.franken.de> <BANLkTi=weyxZDhETjki28kg_a8SadprXSw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, May 12, 2011 at 04:00:35AM +0200, Attilio Rao wrote: > 2011/5/11 Marius Strobl <marius@alchemy.franken.de>: > > On Wed, May 11, 2011 at 11:28:33PM +0200, Attilio Rao wrote: > >> 2011/5/11 Marius Strobl <marius@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110512094152.GV92688>