From owner-freebsd-drivers@FreeBSD.ORG Mon Nov 24 21:56:24 2008 Return-Path: Delivered-To: freebsd-drivers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C8D21065672 for ; Mon, 24 Nov 2008 21:56:24 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id DC8538FC1F for ; Mon, 24 Nov 2008 21:56:23 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id mAOLuMgP049253 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Nov 2008 13:56:22 -0800 (PST) (envelope-from sam@freebsd.org) Message-ID: <492B2306.60404@freebsd.org> Date: Mon, 24 Nov 2008 13:56:22 -0800 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.9 (X11/20071125) MIME-Version: 1.0 To: David Christensen References: <5D267A3F22FD854F8F48B3D2B52381933940B2DEFE@IRVEXCHCCR01.corp.ad.broadcom.com> In-Reply-To: <5D267A3F22FD854F8F48B3D2B52381933940B2DEFE@IRVEXCHCCR01.corp.ad.broadcom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC--Metrics: ebb.errno.com; whitelist Cc: "freebsd-net@FreeBSD.org" , "freebsd-drivers@freebsd.org" Subject: Re: Gathering Hardware State During a Driver Initiated Kernel Panic X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2008 21:56:24 -0000 David Christensen wrote: > Is there a method or callback in FreeBSD where a driver can > be notified that it has caused a kernel panic in order to > generate a dump of internal hardware state information? I've > written a sysctl call for manual intervention and can handle > some "expected" hardware events completely in the driver but > I don't know of a way to get control again in cases where the > driver wasn't expecting a failure. > Not sure how one can deduce a driver is at fault but you might define a ddb command for the driver and invoke that on panic using the ddb script mechanisms (see ddb(4)). Sam