Date: Mon, 28 Mar 2005 16:10:56 +0400 From: Vladimir Grebenschikov <vova@fbsd.ru> To: ticso@cicely.de Cc: Julian Elischer <julian@elischer.org> Subject: Re: Reattach/redetect allways connected umass device - is it possible ? Message-ID: <1112011856.1022.28.camel@localhost> In-Reply-To: <20050328114633.GZ14532@cicely12.cicely.de> References: <1110800717.1296.19.camel@localhost> <20050323205841.N37251@sasami.jurai.net> <77e48641fc04164b4c81cce75c42a38b@FreeBSD.org> <1111648302.3557.10.camel@localhost> <20050328111139.GY14532@cicely12.cicely.de> <1112009710.1022.19.camel@localhost> <20050328114633.GZ14532@cicely12.cicely.de>
next in thread | previous in thread | raw e-mail | index | archive | help
=F7 =D0=CE, 28/03/2005 =D7 13:46 +0200, Bernd Walter =D0=C9=DB=C5=D4: > On Mon, Mar 28, 2005 at 03:35:10PM +0400, Vladimir Grebenschikov wrote: > > ? ??, 28/03/2005 ? 13:11 +0200, Bernd Walter ?????: > > > >=20 > > > > Unfortunately, it seen as not-ejectable media. > > > >=20 > > > > # camcontrol inquiry da0 > > > > pass0: <Sony MSC-U04 3.00> Removable Direct Access SCSI-0 device=20 > > > > pass0: Serial Number 3 > > > > pass0: 40.000MB/s transfers=20 > > > > # > > >=20 > > > It's _removeable_ direct access. > >=20 > > oops, sorry. yes it is mentioned as removable. > >=20 > > > Since this is a memory stick - I don't know how one could remove the > > > flash media from the USB drive. > >=20 > > Just mechanically. > >=20 > > > But this device bug won't hurt as long as you can remove the drive. > >=20 > > I can remove even mounted device. So it is not problem. >=20 > So in fact it is a flash card reader? > In that case removeable is correct. > You shouldn't eject mounted media - FreeBSD locks mounted media, but > since your device can't physically lock it... >=20 > > Problem is that I should do something after replace card by another car= d > > of different size to be able mount new card. >=20 > Yes - as already mentioned on the list by diffrent people: > cp /dev/null > /dev/da0 Yes, this works also, I've already relayed about it.=20 > > camcontrol detach da0; camcontrol rescan all=20 > > helps, but, it should be much better if it will be issued automatically= . >=20 > Yes - GEOM seems to ignore media change signals from drives. > I've added PHK to the recipient list - maybe he has an idea about this > problem. I am even not sure Is there such signal. > However - lots of cheap flash card readers are to stupid for even that. This is on-board in my notebook. But m$win detects disconnection. > You just can't rely on an automatic reread. I already do mount/umount and also should do redetect ... > > > > # usbdevs -v > > > > ... > > > > Controller /dev/usb3: > > > > addr 1: high speed, self powered, config 1, EHCI root hub(0x0000), > > > > Intel(0x0000), rev 1.00 > > > > port 1 powered > > > > port 2 powered > > > > port 3 powered > > > > port 4 powered > > > > port 5 addr 2: high speed, self powered, config 1, USB Memory Stic= k > > > > Slot(0x014d), Sony(0x054c), rev 1.10 > > > > port 6 powered > > > > # > > > >=20 > > > > I guess usb device should be removed on skick removal and back, but= it > > > > does not works :(. > > >=20 > > > So you say that the device still exists after unplugging the USB stic= k? > >=20 > > Yes. >=20 > That shouldn't happen, unless you still have references to that device. > Are you running with latest code? Latest does not build due to error in ndis.=20 Now I have code of 24 March 05. > There were lots of ehci fixes lately. I've seen commits, But not sure that they are related - USB device stays connected even when stick itself removed. > > > This is not the intended behavour. Is it still mounted when you unplu= g? > >=20 > > No. (If be more exact it does not depends on mount state). > > USB device never disappear. Probably it reflect real state, I guess, > > card-reader itself hardwired to USB hub inside notebook and never > > disconnected. > >=20 > > Probably there is kind of disconnect notification on CAM level ?=20 >=20 > The first disconnect notification is from your root hub. > The uhub driver then destroys the umass, which first destroys the > scbus and so on. > If one instance on the chain blocks the whole thing has to wait. >=20 --=20 Vladimir B. Grebenchikov vova@fbsd.ru
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1112011856.1022.28.camel>