From owner-freebsd-mobile@FreeBSD.ORG Tue Mar 29 08:16:17 2005 Return-Path: Delivered-To: freebsd-mobile@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A1AE116A4F7; Tue, 29 Mar 2005 08:16:17 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0E44243D41; Tue, 29 Mar 2005 08:16:17 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.13.3/8.13.1) with ESMTP id j2T8FSXP096247; Tue, 29 Mar 2005 01:15:28 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 29 Mar 2005 01:15:30 -0700 (MST) Message-Id: <20050329.011530.97368915.imp@bsdimp.com> To: ticso@cicely.de, ticso@cicely12.cicely.de From: "M. Warner Losh" In-Reply-To: <20050328144135.GI14532@cicely12.cicely.de> References: <32733.1112019870@critter.freebsd.dk> <20050328143801.GH14532@cicely12.cicely.de> <20050328144135.GI14532@cicely12.cicely.de> 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 cc: current@freebsd.org cc: vova@fbsd.ru cc: mdodd@freebsd.org cc: freebsd-mobile@freebsd.org cc: phk@phk.freebsd.dk cc: julian@elischer.org Subject: Re: Reattach/redetect allways connected umass device - is it possible ? X-BeenThere: freebsd-mobile@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Mobile computing with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2005 08:16:17 -0000 In message: <20050328144135.GI14532@cicely12.cicely.de> Bernd Walter 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