From owner-cvs-all@FreeBSD.ORG Wed Mar 29 00:14:08 2006 Return-Path: X-Original-To: cvs-all@FreeBSD.org Delivered-To: cvs-all@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 96F0416A400; Wed, 29 Mar 2006 00:14:08 +0000 (UTC) (envelope-from marius@FreeBSD.org) Received: from repoman.freebsd.org (repoman.freebsd.org [216.136.204.115]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6237E43D46; Wed, 29 Mar 2006 00:14:08 +0000 (GMT) (envelope-from marius@FreeBSD.org) Received: from repoman.freebsd.org (localhost [127.0.0.1]) by repoman.freebsd.org (8.13.1/8.13.1) with ESMTP id k2T0E8sA079194; Wed, 29 Mar 2006 00:14:08 GMT (envelope-from marius@repoman.freebsd.org) Received: (from marius@localhost) by repoman.freebsd.org (8.13.1/8.13.1/Submit) id k2T0E8Uc079193; Wed, 29 Mar 2006 00:14:08 GMT (envelope-from marius) Message-Id: <200603290014.k2T0E8Uc079193@repoman.freebsd.org> From: Marius Strobl Date: Wed, 29 Mar 2006 00:14:08 +0000 (UTC) To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org X-FreeBSD-CVS-Branch: HEAD Cc: Subject: cvs commit: src/sys/sparc64/sparc64 mp_machdep.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2006 00:14:08 -0000 marius 2006-03-29 00:14:08 UTC FreeBSD src repository Modified files: sys/sparc64/sparc64 mp_machdep.c Log: - We only lock the local per-CPU page in the local dTLB, so accessing the foreign per-CPU pages in cpu_ipi_send() in order to get the module IDs of the other CPUs can cause a page fault. If this happens when doing a TLB shootdown while dealing with another page fault this causes a panic due to the recursive page fault. As I don't spot other code that assumes or requires that accessing foreign per-CPU pages must not page fault solve this by adding a statically allocated (and therefore locked in the kernel pages) array which establishes a FreeBSD CPU ID -> module ID relation and use that in cpu_ipi_selected() (instead of statically allocating the per-CPU pages which would just waste memory on say a dual CPU machine as sun4u theoretically supports up to 128 CPUs or wasting dTLB slots for the foreign per-CPU pages). [1] - Fix a potential race in cpu_ipi_send(); as we don't serialize the access to cpu_ipi_selected() between MI and MD use (only MI-MI and MD-MD) we might catch the NACK bit caused by sending another IPI. Solve this by checking the NACK bit in the contents of the interrupt dispatch status reg read while interrupts were still turned off instead of reading that reg anew after interrupts were turned on again. This is also what the CPU docs suggest to do. - Add a workaround for the SpitFire erratum #54 bug (affecting interrupt dispatch). While public info regarding what this CPU bug actually causes is not available testing shows that with the workaround in place it's less likely to get a "couldn't send ipi" panic, it doesn't solve these panics entirely though. [2] Reported by: kris [1] Some clue from: kmacy [1] Info from: Linux, OpenSolaris [2] Additional testing by: kris MFC after: 3 days Revision Changes Path 1.32 +17 -5 src/sys/sparc64/sparc64/mp_machdep.c