Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 31 Aug 2005 22:58:08 -0600 (MDT)
From:      "M. Warner Losh" <imp@bsdimp.com>
To:        ticso@cicely.de
Cc:        freebsd-current@freebsd.org
Subject:   Re: panic after removing usb flash drive
Message-ID:  <20050831.225808.69990745.imp@bsdimp.com>
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>

next in thread | previous in thread | raw e-mail | index | archive | help
In message: <20050831.224412.98347286.imp@bsdimp.com>
            "M. Warner Losh" <imp@bsdimp.com> writes:
: In message: <20050831174631.GE37930@cicely12.cicely.de>
:             Bernd Walter <ticso@cicely12.cicely.de> 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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050831.225808.69990745.imp>