From owner-freebsd-drivers@FreeBSD.ORG Mon Nov 24 15:33:12 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 4DDA81065672 for ; Mon, 24 Nov 2008 15:33:12 +0000 (UTC) (envelope-from brad.huntting@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.28]) by mx1.freebsd.org (Postfix) with ESMTP id 080148FC18 for ; Mon, 24 Nov 2008 15:33:11 +0000 (UTC) (envelope-from brad.huntting@gmail.com) Received: by yx-out-2324.google.com with SMTP id 8so831276yxb.13 for ; Mon, 24 Nov 2008 07:33:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:reply-to :sender:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition:x-google-sender-auth; bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=; b=xk1aMnuaNBsL8piijlzKjplID/MBdRkNyAziapdCla6rjj+TXBfI0VpJCUCGUnmeRC LQSxtZ50TteRc9VKFXqBnlKVnHm5mWIA4IxOYURioW96U9nQ5LdINzjll8tbCC8e0AnY pJ5QoWGH/HSx1gFtWS74x3Aova7OLQ3SVNwV4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:sender:to:subject:mime-version :content-type:content-transfer-encoding:content-disposition :x-google-sender-auth; b=BMFV+iUSi0bI8Pjol+kY5fznW2Fzne7tGe3m+qEuIL+MIoyBBvOOGPqR0NrhxDI0Iv z6HYtfh3Ode1nz92iqTw9JMAEreR6vq6GDhvYPJosfAHk5NTjQQjRSi5zXwI/xZaVZnJ qqVDOUaotiJrdQDCx1269cQN/yH1Xfavze9UI= Received: by 10.142.230.7 with SMTP id c7mr1685765wfh.251.1227539211474; Mon, 24 Nov 2008 07:06:51 -0800 (PST) Received: by 10.143.7.1 with HTTP; Mon, 24 Nov 2008 07:06:51 -0800 (PST) Message-ID: Date: Mon, 24 Nov 2008 08:06:51 -0700 From: "Brad Huntting" Sender: brad.huntting@gmail.com To: freebsd-drivers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: 7864f6f77a6ab931 Subject: add huntting@glarp.com X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: huntting@glarp.com 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 15:33:12 -0000 From owner-freebsd-drivers@FreeBSD.ORG Mon Nov 24 16:19:35 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 1E9D9106564A for ; Mon, 24 Nov 2008 16:19:35 +0000 (UTC) (envelope-from brad.huntting@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.30]) by mx1.freebsd.org (Postfix) with ESMTP id CBD708FC0C for ; Mon, 24 Nov 2008 16:19:34 +0000 (UTC) (envelope-from brad.huntting@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so843526ywe.13 for ; Mon, 24 Nov 2008 08:19:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:reply-to :sender:to:subject:cc:mime-version:content-type :content-transfer-encoding:content-disposition:x-google-sender-auth; bh=n2kE3yTkvFYffeuC8tnQ45OU7vFc2rp+ihFWjcz7es0=; b=xVxN2pAHPIjWZuyVFA8ttac/vRQxnz8aSgwESRyjuXKzuk0XtzlxQ3GAVn5MbzbG5l 6b+Wvh8NoZegIV4i50BNCBbmnHSUfil8BKdvMN6mdoX5+k4O1jefX1e/b1kWRxYvWpbv 5qVdKFOnXpiZPCEGYJA8DQoaePbro+3ZMf8W8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:sender:to:subject:cc:mime-version :content-type:content-transfer-encoding:content-disposition :x-google-sender-auth; b=XyKYgIozmHOIt70MArXElo/sLigPcPErLl4ofjpMTwy7R7e5F4anTiJa+FZ6MprJmg IaxuJBboVfobTdUXQL5OFvc03NBzyVCA49SpDji/HlS3aJwB1xdD30L6/n5XEpKTMjNx LJ7xpnEe8hhv9I956john7XnHXLvxnazYupu8= Received: by 10.142.246.19 with SMTP id t19mr1586912wfh.332.1227543573663; Mon, 24 Nov 2008 08:19:33 -0800 (PST) Received: by 10.143.7.1 with HTTP; Mon, 24 Nov 2008 08:19:33 -0800 (PST) Message-ID: Date: Mon, 24 Nov 2008 09:19:33 -0700 From: "Brad Huntting" Sender: brad.huntting@gmail.com To: freebsd-drivers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: df965664aa4e1921 Cc: Subject: mutex quandry X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: huntting@glarp.com 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 16:19:35 -0000 Dear hackers: My device driver, like many, maintains a counter (sc_inuse) and a flag (sc_running) to keep track of how many 'users' are using the device instance variables (softc) and wheather the device is trying to detach. I call the functions scm_reserver() and scm_leave() (see below) before and after any block of code that uses the softc. Then, in my detach() function I clear the sc_running flag and msleep() waiting for the sc_inuse counter to drain to zero before continuing, eventually destroying the very mutex I use to protect these two variables. My problem is here: if (sc && mtx_initialized(&sc->sc_inuse_mtx)) { mtx_lock(&sc->sc_inuse_mtx); ... Unfortunately, { mtx_initialized(x) && (mtx_lock(x), 1); } is not atomic. In the unlikely (but possible) event that the lock is destroyed after mtx_initialized(x) and before mtx_lock(x), the system will behave badly (probably panic). It would seem to be a common problem for most device drivers to implement this 'open/closing' lock where the lock starts out zero-filled in the pre-open state and destroyed in the post-closed state. So how should one deal with this? I could invent my own locking with atomic_*() operations, but then I loose the advantages of using standard system locks (like witness). thanx in advance, brad /* * scm_reserve() increments a inuse and scm_release() keep track * of how many customers are on site. To shut down we close the * door (sc_running=0), but we dont actually turn out the lights * untill the last customer has left (sc_inuse==0). * * If device is configured, this returns TRUE and caller must call * scm_release() when done. If device is not configured returns * FALSE and no further action is required. */ static int scm_reserve(struct scmicro_softc *sc) { int r; if (sc && mtx_initialized(&sc->sc_inuse_mtx)) { mtx_lock(&sc->sc_inuse_mtx); KASSERT(sc->sc_inuse >= 0, "scmicro: scm_reserve() sc_inuse <0!\n"); r = ( sc->sc_running ? ++sc->sc_inuse : 0 ); mtx_unlock(&sc->sc_inuse_mtx); } else { r = 0; DPRINTF(("scmicro: scm_reserve() failed to reserve sc=%p!\n", sc)); } return (r); } /* call this iff scm_reserve() returns true. */ static inline void scm_release(struct scmicro_softc *sc) { mtx_lock(&sc->sc_inuse_mtx); if (--sc->sc_inuse == 0) wakeup(&sc->sc_inuse); KASSERT(sc->sc_inuse >= 0, "scmicro: scm_release() sc_inuse <0!\n"); mtx_unlock(&sc->sc_inuse_mtx); } static int scmicro_detach(device_t self) { /*....*/ mtx_lock(&sc->sc_inuse_mtx); sc->sc_running = 0; /* redundant */ if (sc->sc_inuse > 0) msleep_spin((void *)&sc->sc_inuse, &sc->sc_inuse_mtx, "scmicro detach", 0); mtx_unlock(&sc->sc_inuse_mtx); /*....*/ mtx_destroy(&sc->sc_inuse_mtx); /*....*/ } From owner-freebsd-drivers@FreeBSD.ORG Mon Nov 24 17:39:02 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 88A651065672 for ; Mon, 24 Nov 2008 17:39:02 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 3902F8FC18 for ; Mon, 24 Nov 2008 17:39:02 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id mAOHanLw038110; Mon, 24 Nov 2008 10:36:49 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Mon, 24 Nov 2008 10:38:16 -0700 (MST) Message-Id: <20081124.103816.1649771647.imp@bsdimp.com> To: huntting@glarp.com From: "M. Warner Losh" In-Reply-To: References: X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-drivers@freebsd.org Subject: Re: mutex quandry 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 17:39:02 -0000 In message: "Brad Huntting" writes: : Dear hackers: : : My device driver, like many, maintains a counter (sc_inuse) and a flag : (sc_running) to keep track of how many 'users' are using the device : instance variables (softc) and wheather the device is trying to : detach. I call the functions scm_reserver() and scm_leave() (see : below) before and after any block of code that uses the softc. Then, : in my detach() function I clear the sc_running flag and msleep() : waiting for the sc_inuse counter to drain to zero before continuing, : eventually destroying the very mutex I use to protect these two : variables. My problem is here: : : if (sc && mtx_initialized(&sc->sc_inuse_mtx)) { : mtx_lock(&sc->sc_inuse_mtx); : ... : : Unfortunately, { mtx_initialized(x) && (mtx_lock(x), 1); } is not : atomic. In the unlikely (but possible) event that the lock is : destroyed after mtx_initialized(x) and before mtx_lock(x), the system : will behave badly (probably panic). Why do you care that it is initialized? This mutex should be created in the attach routine, and nothing can race it there unless it is creating threads, registering interrupts, etc before initializing it. : It would seem to be a common problem for most device drivers to : implement this 'open/closing' lock where the lock starts out : zero-filled in the pre-open state and destroyed in the post-closed : state. So how should one deal with this? I could invent my own : locking with atomic_*() operations, but then I loose the advantages of : using standard system locks (like witness). Right. I guess I still don't understand why you need to check to see if it is initialized. You should never be destroying the mutex if there are other threads accessing it. I guess I'm having problems understanding why you are even doing the non-atomic test, and why it is needed. Once you remove the test, the code falls into standard norms. Warner : thanx in advance, : brad : : /* : * scm_reserve() increments a inuse and scm_release() keep track : * of how many customers are on site. To shut down we close the : * door (sc_running=0), but we dont actually turn out the lights : * untill the last customer has left (sc_inuse==0). : * : * If device is configured, this returns TRUE and caller must call : * scm_release() when done. If device is not configured returns : * FALSE and no further action is required. : */ : static int : scm_reserve(struct scmicro_softc *sc) : { : int r; : : if (sc && mtx_initialized(&sc->sc_inuse_mtx)) { : mtx_lock(&sc->sc_inuse_mtx); : KASSERT(sc->sc_inuse >= 0, "scmicro: scm_reserve() : sc_inuse <0!\n"); : r = ( sc->sc_running ? ++sc->sc_inuse : 0 ); : mtx_unlock(&sc->sc_inuse_mtx); : } else { : r = 0; : DPRINTF(("scmicro: scm_reserve() failed to reserve : sc=%p!\n", sc)); : } : : return (r); : } : : /* call this iff scm_reserve() returns true. */ : static inline void : scm_release(struct scmicro_softc *sc) : { : : mtx_lock(&sc->sc_inuse_mtx); : if (--sc->sc_inuse == 0) : wakeup(&sc->sc_inuse); : KASSERT(sc->sc_inuse >= 0, "scmicro: scm_release() sc_inuse <0!\n"); : mtx_unlock(&sc->sc_inuse_mtx); : } : : static int : scmicro_detach(device_t self) : { : /*....*/ : mtx_lock(&sc->sc_inuse_mtx); : sc->sc_running = 0; /* redundant */ : if (sc->sc_inuse > 0) : msleep_spin((void *)&sc->sc_inuse, &sc->sc_inuse_mtx, : "scmicro detach", 0); : mtx_unlock(&sc->sc_inuse_mtx); : /*....*/ : mtx_destroy(&sc->sc_inuse_mtx); : /*....*/ : } : _______________________________________________ : freebsd-drivers@freebsd.org mailing list : http://lists.freebsd.org/mailman/listinfo/freebsd-drivers : To unsubscribe, send any mail to "freebsd-drivers-unsubscribe@freebsd.org" : : From owner-freebsd-drivers@FreeBSD.ORG Mon Nov 24 19:40:16 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 587331065670 for ; Mon, 24 Nov 2008 19:40:16 +0000 (UTC) (envelope-from huntting@glarp.com) Received: from antediluvian.glarp.com (71-212-184-155.hlrn.qwest.net [71.212.184.155]) by mx1.freebsd.org (Postfix) with ESMTP id E4DEE8FC17 for ; Mon, 24 Nov 2008 19:40:15 +0000 (UTC) (envelope-from huntting@glarp.com) Received: from antediluvian.glarp.com (localhost [127.0.0.1]) by antediluvian.glarp.com (8.14.2/8.14.2) with ESMTP id mAOJBVkM067002; Mon, 24 Nov 2008 12:11:32 -0700 (MST) (envelope-from huntting@antediluvian.glarp.com) Message-Id: <200811241911.mAOJBVkM067002@antediluvian.glarp.com> To: "M. Warner Losh" From: Brad Huntting In-Reply-To: Your message of "Mon, 24 Nov 2008 10:38:16 MST." <20081124.103816.1649771647.imp@bsdimp.com> Date: Mon, 24 Nov 2008 12:11:31 -0700 Sender: huntting@glarp.com Cc: freebsd-drivers@freebsd.org Subject: Re: mutex quandry 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 19:40:16 -0000 >: Dear hackers: >: >: My device driver, like many, maintains a counter (sc_inuse) and a flag >: (sc_running) to keep track of how many 'users' are using the device >: instance variables (softc) and wheather the device is trying to >: detach. I call the functions scm_reserver() and scm_leave() (see >: below) before and after any block of code that uses the softc. Then, >: in my detach() function I clear the sc_running flag and msleep() >: waiting for the sc_inuse counter to drain to zero before continuing, >: eventually destroying the very mutex I use to protect these two >: variables. My problem is here: >: >: if (sc && mtx_initialized(&sc->sc_inuse_mtx)) { >: mtx_lock(&sc->sc_inuse_mtx); >: ... >: >: Unfortunately, { mtx_initialized(x) && (mtx_lock(x), 1); } is not >: atomic. In the unlikely (but possible) event that the lock is >: destroyed after mtx_initialized(x) and before mtx_lock(x), the system >: will behave badly (probably panic). > >Why do you care that it is initialized? This mutex should be created >in the attach routine, and nothing can race it there unless it is >creating threads, registering interrupts, etc before initializing it. I meant to check if it's been destroyed. Does mtx_initialized() not do this? >: It would seem to be a common problem for most device drivers to >: implement this 'open/closing' lock where the lock starts out >: zero-filled in the pre-open state and destroyed in the post-closed >: state. So how should one deal with this? I could invent my own >: locking with atomic_*() operations, but then I loose the advantages of >: using standard system locks (like witness). > >Right. I guess I still don't understand why you need to check to see >if it is initialized. You should never be destroying the mutex if >there are other threads accessing it. My own threads will certainly be gone by the time I destroy the mutex. But this particular device has methods for kernel level consumers (with they're own threads). It's these methods that need to check to see if the device is still running. They can get the softc and check (sc && sc->sc_running). But to ensure the device doesnt go away while they're using it, they increment the counter sc_inuse. The combination of checking sc_running and incrementing sc_inuse needs to be atomic (hence a mutex around them) but at some point detach() has to destroy the mutex but my code may still need to use it. My solution was to use mtx_inialized() to see if they lock had been destroyed before trying to mtx_lock() it. I'm beginning to think that I should avoid a mutex entirely and somehow use just atomic_*() ops. >I guess I'm having problems understanding why you are even doing the >non-atomic test, and why it is needed. Once you remove the test, the >code falls into standard norms. > >Warner > > >: thanx in advance, >: brad >: >: /* >: * scm_reserve() increments a inuse and scm_release() keep track >: * of how many customers are on site. To shut down we close the >: * door (sc_running=0), but we dont actually turn out the lights >: * untill the last customer has left (sc_inuse==0). >: * >: * If device is configured, this returns TRUE and caller must call >: * scm_release() when done. If device is not configured returns >: * FALSE and no further action is required. >: */ >: static int >: scm_reserve(struct scmicro_softc *sc) >: { >: int r; >: >: if (sc && mtx_initialized(&sc->sc_inuse_mtx)) { >: mtx_lock(&sc->sc_inuse_mtx); >: KASSERT(sc->sc_inuse >= 0, "scmicro: scm_reserve() >: sc_inuse <0!\n"); >: r = ( sc->sc_running ? ++sc->sc_inuse : 0 ); >: mtx_unlock(&sc->sc_inuse_mtx); >: } else { >: r = 0; >: DPRINTF(("scmicro: scm_reserve() failed to reserve >: sc=%p!\n", sc)); >: } >: >: return (r); >: } >: >: /* call this iff scm_reserve() returns true. */ >: static inline void >: scm_release(struct scmicro_softc *sc) >: { >: >: mtx_lock(&sc->sc_inuse_mtx); >: if (--sc->sc_inuse == 0) >: wakeup(&sc->sc_inuse); >: KASSERT(sc->sc_inuse >= 0, "scmicro: scm_release() sc_inuse <0!\n"); >: mtx_unlock(&sc->sc_inuse_mtx); >: } >: >: static int >: scmicro_detach(device_t self) >: { >: /*....*/ >: mtx_lock(&sc->sc_inuse_mtx); >: sc->sc_running = 0; /* redundant */ >: if (sc->sc_inuse > 0) >: msleep_spin((void *)&sc->sc_inuse, &sc->sc_inuse_mtx, >: "scmicro detach", 0); >: mtx_unlock(&sc->sc_inuse_mtx); >: /*....*/ >: mtx_destroy(&sc->sc_inuse_mtx); >: /*....*/ >: } From owner-freebsd-drivers@FreeBSD.ORG Mon Nov 24 20:42:04 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 9EF241065689 for ; Mon, 24 Nov 2008 20:42:04 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 4B9238FC12 for ; Mon, 24 Nov 2008 20:42:04 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id mAOKf8iD040496; Mon, 24 Nov 2008 13:41:08 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Mon, 24 Nov 2008 13:42:36 -0700 (MST) Message-Id: <20081124.134236.723203643.imp@bsdimp.com> To: huntting@glarp.com From: "M. Warner Losh" In-Reply-To: <200811241911.mAOJBVkM067002@antediluvian.glarp.com> References: <20081124.103816.1649771647.imp@bsdimp.com> <200811241911.mAOJBVkM067002@antediluvian.glarp.com> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-drivers@FreeBSD.org Subject: Re: mutex quandry 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 20:42:04 -0000 In message: <200811241911.mAOJBVkM067002@antediluvian.glarp.com> Brad Huntting writes: : The combination of checking sc_running and incrementing sc_inuse : needs to be atomic (hence a mutex around them) but at some point : detach() has to destroy the mutex but my code may still need to use : it. Your solution to this is to make sure that never happens. Anything else is really racy. If you are destroying your mutex and allowing detach to return, the entire sc is freed, so you're dead from that anyway... Warner From owner-freebsd-drivers@FreeBSD.ORG Mon Nov 24 21:46:15 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 68AF41065674; Mon, 24 Nov 2008 21:46:15 +0000 (UTC) (envelope-from davidch@broadcom.com) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by mx1.freebsd.org (Postfix) with ESMTP id 2C0F88FC1A; Mon, 24 Nov 2008 21:46:15 +0000 (UTC) (envelope-from davidch@broadcom.com) Received: from [10.11.16.99] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Mon, 24 Nov 2008 13:31:59 -0800 X-Server-Uuid: B55A25B1-5D7D-41F8-BC53-C57E7AD3C201 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id DF5CC2B1; Mon, 24 Nov 2008 13:31:58 -0800 (PST) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.11.18.52]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id CB3402B0; Mon, 24 Nov 2008 13:31:58 -0800 (PST) Received: from mail-irva-13.broadcom.com (mail-irva-13.broadcom.com [10.11.16.103]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id HIC95391; Mon, 24 Nov 2008 13:31:57 -0800 (PST) Received: from IRVEXCHHUB01.corp.ad.broadcom.com (irvexchhub01 [10.9.200.131]) by mail-irva-13.broadcom.com (Postfix) with ESMTP id AB9AD74CFE; Mon, 24 Nov 2008 13:31:57 -0800 (PST) Received: from IRVEXCHCCR01.corp.ad.broadcom.com ([10.252.49.30]) by IRVEXCHHUB01.corp.ad.broadcom.com ([10.9.200.131]) with mapi; Mon, 24 Nov 2008 13:31:57 -0800 From: "David Christensen" To: "freebsd-drivers@freebsd.org" , "freebsd-net@FreeBSD.org" Date: Mon, 24 Nov 2008 13:33:50 -0800 Thread-Topic: Gathering Hardware State During a Driver Initiated Kernel Panic Thread-Index: AclOfE8KvODwR+q4Q0S7pWqp+3T1AA== Message-ID: <5D267A3F22FD854F8F48B3D2B52381933940B2DEFE@IRVEXCHCCR01.corp.ad.broadcom.com> Accept-Language: en-US Content-Language: en-US acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 6535C2C537G20288383-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: Subject: 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:46:15 -0000 Is there a method or callback in FreeBSD where a driver can=20 be notified that it has caused a kernel panic in order to=20 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=20 driver wasn't expecting a failure. Dave 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 From owner-freebsd-drivers@FreeBSD.ORG Tue Nov 25 17:22:09 2008 Return-Path: Delivered-To: drivers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 959DE1065672 for ; Tue, 25 Nov 2008 17:22:09 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 5F5788FC08 for ; Tue, 25 Nov 2008 17:22:09 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id mAPHJ0bH060387; Tue, 25 Nov 2008 10:19:00 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 25 Nov 2008 10:20:30 -0700 (MST) Message-Id: <20081125.102030.-1272479009.imp@bsdimp.com> To: huntting@glarp.com From: "M. Warner Losh" In-Reply-To: <200811251707.mAPH7JRg090619@antediluvian.glarp.com> References: <20081124.134236.723203643.imp@bsdimp.com> <200811251707.mAPH7JRg090619@antediluvian.glarp.com> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: drivers@FreeBSD.org Subject: Re: mutex quandry 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: Tue, 25 Nov 2008 17:22:09 -0000 In message: <200811251707.mAPH7JRg090619@antediluvian.glarp.com> Brad Huntting writes: : : >: The combination of checking sc_running and incrementing sc_inuse : >: needs to be atomic (hence a mutex around them) but at some point : >: detach() has to destroy the mutex but my code may still need to use : >: it. : > : >Your solution to this is to make sure that never happens. Anything : >else is really racy. If you are destroying your mutex and allowing : >detach to return, the entire sc is freed, so you're dead from that : >anyway... : : Fair enough. I guess I was just too focused on my small part of : the larger system. : : But that brings up another issue. How do my (kernel level) users : know if my module is loaded or not? I cant find any section 9 docs : on kernal loadable modules. Am I looking in the wrong place? Or : do I just need to read the source. It should be documented in section 9. Use level users can do a kldstat to find this information. I think kern_kldload will load the module, but I'm not sure how to get status. I've cc'd drivers@ to see if someone there knows. Warner