From owner-freebsd-current@FreeBSD.ORG Tue Feb 22 22:59:35 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F3BDE16A4E3; Tue, 22 Feb 2005 22:59:34 +0000 (GMT) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.199.47.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id B24D243D2D; Tue, 22 Feb 2005 22:59:34 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 7A80851473; Tue, 22 Feb 2005 14:59:32 -0800 (PST) Date: Tue, 22 Feb 2005 14:59:32 -0800 From: Kris Kennaway To: John Baldwin Message-ID: <20050222225932.GA90362@xor.obsecurity.org> References: <200502111148.45976.jhb@FreeBSD.org> <200502221620.27992.jhb@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+QahgC5+KEYLbs62" Content-Disposition: inline In-Reply-To: <200502221620.27992.jhb@FreeBSD.org> User-Agent: Mutt/1.4.2.1i cc: freebsd-current@FreeBSD.org cc: Alan Cox cc: current@FreeBSD.org cc: jeffr@FreeBSD.org cc: Julian Elischer Subject: Re: HEADSUP: Turn off cpu_idle_hlt on SMP for now on x86 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2005 22:59:35 -0000 --+QahgC5+KEYLbs62 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Feb 22, 2005 at 04:20:27PM -0500, John Baldwin wrote: > On Friday 11 February 2005 11:48 am, John Baldwin wrote: > > Thus, my theory is that when the pinned thread was preempted and put ba= ck > > on the run queue, the scheduler didn't IPI the CPU it was pinned to to = wake > > it up in case it was idle. The IPI is only needed if the CPUs are halt= ed, > > which is why I think turning the idle halt off might work as a workarou= nd.=20 > > I don't know if ULE has this same issue, but I've cc'd Jeff and hopeful= ly > > he can look into it. >=20 > Nevermind, I don't think cpu_idle_hlt will help (though it has seemed to = help=20 > locally oddly enough). Presumably the CPU that the preempted thread owni= ng=20 > the vm page queues lock would have run the pinned thread before going idl= e. =20 > In this case, that means that the thread must be pinned to CPU 0 which is= =20 > running a make process that is just spinning. Unfortunately we currently= =20 > don't have a good way of looking at the stack for an thread on another CP= U. I'm running into this with deadlocks I'm seeing on a quad-cpu RELENG_5 sparc machine. Unfortunately, I can't even dump because of yet more locking assertion failures in the dump path (CAM, elsewhere). Kris --+QahgC5+KEYLbs62 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCG7lTWry0BWjoQKURAsA1AKDu+7tRT/PjM5cfKGW+vuO4KMU6XwCg5ENV cH+LjnG2bV85Sfh+49cZDHE= =m4EN -----END PGP SIGNATURE----- --+QahgC5+KEYLbs62--