From owner-freebsd-current@FreeBSD.ORG Thu Sep 1 05:00:28 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 71F6316A420 for ; Thu, 1 Sep 2005 05:00:28 +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 1114C43D45 for ; Thu, 1 Sep 2005 05:00:28 +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 j814vgS9016697; Wed, 31 Aug 2005 22:57:42 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 31 Aug 2005 22:58:08 -0600 (MDT) Message-Id: <20050831.225808.69990745.imp@bsdimp.com> To: ticso@cicely.de From: "M. Warner Losh" In-Reply-To: <20050831.224412.98347286.imp@bsdimp.com> References: <4315CEEC.80100@samsco.org> <20050831174631.GE37930@cicely12.cicely.de> <20050831.224412.98347286.imp@bsdimp.com> 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]); Wed, 31 Aug 2005 22:57:42 -0600 (MDT) Cc: freebsd-current@freebsd.org Subject: Re: panic after removing usb flash drive X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2005 05:00:28 -0000 In message: <20050831.224412.98347286.imp@bsdimp.com> "M. Warner Losh" writes: : In message: <20050831174631.GE37930@cicely12.cicely.de> : Bernd Walter writes: : : Yes - umass creates a SIM, bus and targed, because that is what a user : : really attaches/detaches. : : For what it is worth, in the PC Card and CardBus case, the drivers : aren't allowed to 'fail' the detach. They are required to succeed, : and are removed from the driver tree if they try to return a failure : code. All their resources are removed and interrupts are removed. : The hardware is gone, and the driver has no say so about going away. : At least that's the model we currently have. Also, in detach, drivers are supposed to wait for all their references to go away before returning. If they have any threads running, it is their job to clean them up, etc. This means, however, that cam PC Card and CardBus drivers have issues detaching (since CAM has issues detaching SIMs). Hopefully your work with CAM will help this situation, and I look forward to it. Having a virtual driver that attaches to the physical driver, like we talked about in IRC, wouldn't violate those assumptions. Warner