From owner-cvs-src-old@FreeBSD.ORG Mon Dec 22 15:34:12 2008 Return-Path: Delivered-To: cvs-src-old@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 54BA2106576E for ; Mon, 22 Dec 2008 15:34:12 +0000 (UTC) (envelope-from marius@FreeBSD.org) Received: from repoman.freebsd.org (repoman.freebsd.org [IPv6:2001:4f8:fff6::29]) by mx1.freebsd.org (Postfix) with ESMTP id 3CE6F8FC16 for ; Mon, 22 Dec 2008 15:34:12 +0000 (UTC) (envelope-from marius@FreeBSD.org) Received: from repoman.freebsd.org (localhost [127.0.0.1]) by repoman.freebsd.org (8.14.3/8.14.3) with ESMTP id mBMFYCsM081478 for ; Mon, 22 Dec 2008 15:34:12 GMT (envelope-from marius@repoman.freebsd.org) Received: (from svn2cvs@localhost) by repoman.freebsd.org (8.14.3/8.14.3/Submit) id mBMFYCuI081477 for cvs-src-old@freebsd.org; Mon, 22 Dec 2008 15:34:12 GMT (envelope-from marius@repoman.freebsd.org) Message-Id: <200812221534.mBMFYCuI081477@repoman.freebsd.org> X-Authentication-Warning: repoman.freebsd.org: svn2cvs set sender to marius@repoman.freebsd.org using -f From: Marius Strobl Date: Mon, 22 Dec 2008 15:34:06 +0000 (UTC) To: cvs-src-old@freebsd.org X-FreeBSD-CVS-Branch: HEAD Subject: cvs commit: src/sys/sparc64/sparc64 mp_machdep.c X-BeenThere: cvs-src-old@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: **OBSOLETE** CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Dec 2008 15:34:12 -0000 marius 2008-12-22 15:34:06 UTC FreeBSD src repository Modified files: sys/sparc64/sparc64 mp_machdep.c Log: SVN rev 186395 on 2008-12-22 15:34:06Z by marius - According to comments in OpenBSD, E{2,4}50 tend to have fragile firmware versions which wedge when using the OFW test service, so given that we don't really depend on SUNW,stop-self just nuke it altogether instead of risking problems. - At least Fire V880 have a small hardware glitch which causes the reception of IDR_NACKs for CPUs we actually haven't tried to send an IPI to, even not as part of the initial try. According to tests this apparently can be safely ignored though, so just return if checking for the individual IDR_NACKs indicates no outstanding dispatch. Serializing the sending of IPIs between MD and MI code by the combined usage of smp_ipi_mtx makes no difference to this phenomenon. [1] - Provide relevant debugging bits already with the initial panic in case of problems with the IPI dispatch, which would have allowed to diagnose the above problem without a specially built kernel. - In case of cheetah_ipi_selected() base the delay we wait for other CPUs which also might want to dispatch IPIs on the total amount of CPUs instead of just the number of CPUs we let this CPU send IPIs to because in the worst case all CPUs also want to IPI us at the same time. Reported and access for extensive tests provided by: Beat Gaetzi [1] Revision Changes Path 1.50 +12 -28 src/sys/sparc64/sparc64/mp_machdep.c