Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 29 Mar 2005 01:15:30 -0700 (MST)
From:      "M. Warner Losh" <imp@bsdimp.com>
To:        ticso@cicely.de, ticso@cicely12.cicely.de
Cc:        julian@elischer.org
Subject:   Re: Reattach/redetect allways connected umass device - is it possible ?
Message-ID:  <20050329.011530.97368915.imp@bsdimp.com>
In-Reply-To: <20050328144135.GI14532@cicely12.cicely.de>
References:  <32733.1112019870@critter.freebsd.dk> <20050328143801.GH14532@cicely12.cicely.de> <20050328144135.GI14532@cicely12.cicely.de>

next in thread | previous in thread | raw e-mail | index | archive | help
In message: <20050328144135.GI14532@cicely12.cicely.de>
            Bernd Walter <ticso@cicely12.cicely.de> writes:
: On Mon, Mar 28, 2005 at 04:38:02PM +0200, Bernd Walter wrote:
: > On Mon, Mar 28, 2005 at 04:24:30PM +0200, Poul-Henning Kamp wrote:
: > > In message <20050328134856.GF14532@cicely12.cicely.de>, Bernd Walter writes:
: > > 
: > > >> Driver support for this is not really meaterialized and therefore
: > > >> the model now is that when the media is ejected the geom device
: > > >> is removed and a new one created right away, even if a new media
: > > >> is not inserted right away.
: > > >
: > > >Do you get eject notifications from any device type?
: > > 
: > > Right now I belive floppy disks DTRT.
: > 
: > Interesting.
: > 
: > > >One of my problems is that it is possible with SCSI MO drives to
: > > >eject the media, reinsert a new one and errously continue to work
: > > >with the old GEOM layout.
: > > >I already trashed the data on one media by forgetting to trigger
: > > >a reprobe - since then I use a mount script.
: > > 
: > > Well, I have no idea how to pull the information out of the CAM/SCSI
: > > code, but I'm sure there is _some_ way it can be done.
: > 
: > There is the test unit ready command.
: > Either it returns OK, or you may get usefull sense data.
: > Here is an example:
: 
: This even works for my USB flash drives:
: [67]cicely13# camcontrol tur -n da -u 1 -v
: Unit is not ready
: (pass1:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 
: (pass1:umass-sim0:0:0:0): CAM Status: SCSI Status Error
: (pass1:umass-sim0:0:0:0): SCSI Status: Check Condition
: (pass1:umass-sim0:0:0:0): NOT READY asc:3a,0
: (pass1:umass-sim0:0:0:0): Medium not present
: Exit 1
: [68]cicely13# camcontrol tur -n da -u 1 -v
: Unit is not ready
: (pass1:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 
: (pass1:umass-sim0:0:0:0): CAM Status: SCSI Status Error
: (pass1:umass-sim0:0:0:0): SCSI Status: Check Condition
: (pass1:umass-sim0:0:0:0): UNIT ATTENTION asc:28,0
: (pass1:umass-sim0:0:0:0): Not ready to ready change, medium may have changed
: Exit 1
: [69]cicely13# camcontrol tur -n da -u 1 -v
: Unit is ready
: 
: [71]cicely13# camcontrol tur -n da -u 4 -v
: Unit is not ready
: (pass4:umass-sim1:1:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 
: (pass4:umass-sim1:1:0:0): CAM Status: SCSI Status Error
: (pass4:umass-sim1:1:0:0): SCSI Status: Check Condition
: (pass4:umass-sim1:1:0:0): UNIT ATTENTION asc:28,0
: (pass4:umass-sim1:1:0:0): Not ready to ready change, medium may have changed
: Exit 1
: [72]cicely13# camcontrol tur -n da -u 4 -v
: Unit is ready
: 
: Those are both more or less random flash card readers, so it seems that
: even cheap devices work.

Maybe we should move the TUR processing into daopen?  Right now we
assume that the values from XPT_CALC_GEOMETRY are invairant and we
never need to check to see if they've changed.  Since daopen isn't
usually called that often, optimizing it isn't really much of an
issue.

Warner



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