From owner-freebsd-stable@FreeBSD.ORG Mon Mar 15 17:30:41 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0BDDC1065673 for ; Mon, 15 Mar 2010 17:30:41 +0000 (UTC) (envelope-from matthew.fleming@isilon.com) Received: from seaxch09.isilon.com (seaxch09.isilon.com [74.85.160.25]) by mx1.freebsd.org (Postfix) with ESMTP id E2F818FC2D for ; Mon, 15 Mar 2010 17:30:40 +0000 (UTC) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 15 Mar 2010 10:30:37 -0700 Message-ID: <06D5F9F6F655AD4C92E28B662F7F853E037DDA15@seaxch09.desktop.isilon.com> In-Reply-To: <4B9E2DFD.2000701@zedat.fu-berlin.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Fatal trap 12: page fault while in kernel mode/current process: 12 (swi2: cambio) Thread-Index: AcrEPnaLF/DFxx1cSa26FhCjGjcTigAJki7Q References: <4B9E2DFD.2000701@zedat.fu-berlin.de> From: "Matthew Fleming" To: "O. Hartmann" , Cc: Subject: RE: Fatal trap 12: page fault while in kernel mode/current process: 12 (swi2: cambio) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 17:30:41 -0000 > Since the last update and make world on Friday, 12th March I get a crash > on one of my FreeBSD SMP boxes (it is always the same core message), > saying something about >=20 > Fatal trap 12: page fault while in kernel mode [...] current process: 12 > (swi2: cambio) Can you show the stack traceback from the kernel core? We had a problem a while ago at Isilon that I can't tell if it's related. In our case, the camisr() routine was called after panic(9) started and before the halt of other processors. This did Bad Things(TM) since the mtx_lock is a no-op after panicstr is set. We solved it locally by wrapping camisr() in a local cambio_swi() routine that only called camisr(NULL) when panicstr =3D=3D NULL. Thanks, matthew