Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 12 May 2011 13:43:58 +0300
From:      Andriy Gapon <avg@FreeBSD.org>
To:        Stanislav Sedov <stas@FreeBSD.org>
Cc:        svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, Jung-uk Kim <jkim@FreeBSD.org>
Subject:   Re: svn commit: r221703 - in head/sys: amd64/include i386/include x86/isa x86/x86
Message-ID:  <4DCBB9EE.8070809@FreeBSD.org>
In-Reply-To: <20110512024956.996cd973.stas@FreeBSD.org>
References:  <201105091734.p49HY0P3006180@svn.freebsd.org> <20110512024956.996cd973.stas@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
on 12/05/2011 12:49 Stanislav Sedov said the following:
> On Mon, 9 May 2011 17:34:00 +0000 (UTC)
> Jung-uk Kim <jkim@FreeBSD.org> mentioned:
> 
>> Author: jkim
>> Date: Mon May  9 17:34:00 2011
>> New Revision: 221703
>> URL: http://svn.freebsd.org/changeset/base/221703
>>
>> Log:
>>   Implement boot-time TSC synchronization test for SMP.  This test is executed
>>   when the user has indicated that the system has synchronized TSCs or it has
>>   P-state invariant TSCs.  For the former case, we may clear the tunable if it
>>   fails the test to prevent accidental foot-shooting.  For the latter case, we
>>   may set it if it passes the test to notify the user that it may be usable.
>>
> 
> Hi, Jung-uk!
> 
> My kernel no longer boots on my Dual Xeon Dell Precision after this
> commit.  It hangs immediately after the "AP launched" messages.
> 
> I uploaded my verbose boot log from the old kernel to
> http://www.SpringDaemons.com/stas/boot.verbose

I believe that this was the first stress test for smp_rendezvous() that has
uncovered a bug in it.  I think that a fix similar to what I committed in my xcpu
branch is needed.

Theory:
- smp_rv_waiters[2] becomes equal to smp_rv_ncpus
- [at least] one slave CPU is still in the last call to cpu_spinwait() in
smp_rendezvous_action()
- master CPU notices that the condition is true, exits smp_rendezvous_cpus() and
calls it again
- the slave CPU is still in spinwait
- the master CPU resets smp_rv_waiters[2] to zero
- the slave CPU exits spinwait, see smp_rv_waiters[2] with zero value
- endless loop

-- 
Andriy Gapon



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4DCBB9EE.8070809>