From owner-cvs-all@FreeBSD.ORG Sat Nov 19 21:44:31 2005 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 435B916A41F; Sat, 19 Nov 2005 21:44:31 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6DB6543D49; Sat, 19 Nov 2005 21:44:30 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id jAJLfxhp016842; Sat, 19 Nov 2005 14:41:59 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Sat, 19 Nov 2005 14:42:10 -0700 (MST) Message-Id: <20051119.144210.122123926.imp@bsdimp.com> To: damien.bergamini@free.fr From: "M. Warner Losh" In-Reply-To: <00ca01c5ed4a$86b0e570$0300a8c0@COMETE> References: <20051119165547.0A4BD16A43D@hub.freebsd.org> <437F82A1.6080504@root.org> <00ca01c5ed4a$86b0e570$0300a8c0@COMETE> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Sat, 19 Nov 2005 14:42:14 -0700 (MST) Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org, nate@root.org Subject: Re: cvs commit: src/sys/modules/iwi Makefile src/sys/dev/iwi if_iwi.c if_iwireg.h if_iwivar.h 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: Sat, 19 Nov 2005 21:44:31 -0000 In message: <00ca01c5ed4a$86b0e570$0300a8c0@COMETE> "Damien Bergamini" writes: : | I'm a little concerned about this change. The notes claim the firmware : | is loaded after a resume from the filesystem as well as at : | initialization time. So your driver is then assuming the ATA driver is : | fully reinitialized before your driver's resume method can be called. : | You can't assume that since it's not a child device of ATA. : : Wouldn't the call to VOP_READ block until "/" is recovered in that case ? If it blocks until "/" is recovered, then the system will block. We presently restore single threaded, and if anything in there blocks, we wait until it unblocks. Interrupts are runnable, so some things would still work... Warner