From owner-freebsd-stable@FreeBSD.ORG Sun Mar 21 04:39:00 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 D9363106564A for ; Sun, 21 Mar 2010 04:39:00 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 895528FC0C for ; Sun, 21 Mar 2010 04:39:00 +0000 (UTC) Received: by gyg13 with SMTP id 13so519253gyg.13 for ; Sat, 20 Mar 2010 21:39:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:date:from:to:cc :subject:in-reply-to:message-id:references:user-agent :x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; bh=eMzQrVMYRQk9SXd82NnbdO+U1Aq1jn59ePL4C01tFmY=; b=rN2maHasqfZG4nJT0X9daahcPwMdxjsNPLbtPsX2TjWNmR45e0NsQHImEmIvEeuZa/ /BuuaMOwFKSmqovn2W1pF3RYUDBik6jmUuzNfdXX+/Rzu5BkZR7at2XDPWkPkL8DP3J8 0hYyron+QQTAybj0l4jJYQDRZ71Ggl/7Agv74= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; b=CJPVPkYO3naMK+9BRAHP2WUT5VVSSF5MJ4eANePsiLAgFLZmD5i5qS0OYtw7ZotQFe abFVxb2I5quOaBzhmWFZnx3RwEl1RhwJqAstS8PI8/xRUAdabf0hCCGjO8W+E2gzYOge uNZJwHytQfjKCxrSM4cNMXBtpwOVe/zN440zw= Received: by 10.150.173.8 with SMTP id v8mr5900522ybe.338.1269146339719; Sat, 20 Mar 2010 21:38:59 -0700 (PDT) Received: from centel.dataix.local (ppp-23.100.dialinfree.com [209.172.23.100]) by mx.google.com with ESMTPS id 20sm1194793iwn.13.2010.03.20.21.38.50 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 20 Mar 2010 21:38:58 -0700 (PDT) Sender: "J. Hellenthal" Date: Sun, 21 Mar 2010 00:39:01 -0400 From: jhell To: "O. Hartmann" In-Reply-To: <4BA294F7.4030209@mail.zedat.fu-berlin.de> Message-ID: References: <4B9E2DFD.2000701@zedat.fu-berlin.de> <06D5F9F6F655AD4C92E28B662F7F853E037DDA15@seaxch09.desktop.isilon.com> <4B9EBCE5.7080303@mail.zedat.fu-berlin.de> <4BA294F7.4030209@mail.zedat.fu-berlin.de> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org, Matthew Fleming 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: Sun, 21 Mar 2010 04:39:01 -0000 On Thu, 18 Mar 2010 17:02, O. Hartmann wrote: In Message-Id: <4BA294F7.4030209@mail.zedat.fu-berlin.de> > On 03/16/10 00:04, O. Hartmann wrote: >> On 03/15/10 18:30, Matthew Fleming wrote: >>>> 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 >>>> >>>> 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 == NULL. >>> >>> Thanks, >>> matthew >> >> Hello. >> >> I will do as soon as possible. The box is in production at the moment >> and I've less time to put everything into debugging to provide more >> details. >> >> Just in case: does the kernel automatically save the screen with the >> dump information? If not, I have no other terminal facility to get a >> dump via the classical way. >> >> Regards, >> Oliver > > Since yesterday, this problem went away! This is mystical. After deactivating > radeon.ko and the virtual box stuff I tried again with a new build of world > and - voila! - everything worked again. This is strange ... > > Oliver > If possible set a dump device and use the following in your rc.conf: crashinfo_enable="YES" dumpdev="ADD-DEVICE-HERE" After the crash happens look for core.txt.N files in /var/crash. You will probably want to look over the crash info and scrub it of vital information to comply with your companies policies. It is very verbose. DDB as I have heard can be configured AFAIR to textdump but I have no knowledge of that. Good Luck, -- jhell