Re: Reattach/redetect allways connected umass device - is it possible ?

Bernd Walter <[email protected]>
Newsgroups gmane.os.freebsd.current,gmane.os.freebsd.devel.mobile
Message-ID <[email protected]>
On Mon, Mar 28, 2005 at 06:06:10PM +0400, Vladimir Grebenschikov wrote:
> ? ??, 28/03/2005 ? 15:28 +0200, Bernd Walter ?????:
> > On Mon, Mar 28, 2005 at 05:17:24PM +0400, Vladimir Grebenschikov wrote:
> > > ? ??, 28/03/2005 ? 15:04 +0200, Bernd Walter ?????:
> > > > On Mon, Mar 28, 2005 at 04:58:31PM +0400, Vladimir Grebenschikov wrote:
> > > > > ? ??, 28/03/2005 ? 14:13 +0200, Poul-Henning Kamp ?????:
> > > > > > In message <[email protected]>, Bernd Walter writes:
> > > > > > 
> > > > > > >> camcontrol detach da0; camcontrol rescan all 
> > > > > > >> helps, but, it should be much better if it will be issued automatically.
> > > > > > >
> > > > > > >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.
> > > > > > 
> > > > > > No, GEOM doesn't ignore any such thing, because as far as I know
> > > > > > GEOM doesn't get any such thing to ignore in the first place.
> > > > > 
> > > > > So, let's imagine following situation:
> > > > > 
> > > > > We get SCSI BUS with removable da device.
> > > > > device detected as da0 and not mounted.
> > > > > Device disconnected from SCSI bus.
> > > > > And finally, another device with different geometry connected with same
> > > > > SCIS ID.
> > > > 
> > > > This ist not a *media* exchange - this is a *device* and in
> > > > this case even a scbus exchange.
> > > 
> > > Ok, so my case is media exchange, not device exchange.
> > 
> > No - it is a device exchange.
> > GEOM only has problems with media exchange.
> > A new device is no problem for GEOM.
> > Your problem is very likely not GEOM related.
> 
> I guess, may bad example messed up discussion. sorry.
> 
> >From begin:
>   I have USB-connected card-reader (Sony Memory Stick).
>   It connected as umass0 (ehci), then as da0.
>   It can't be unplugged. (on-board notebook device)

OK - then I got you wrong here - so you are really exchanging just
the media.
Yes - the thread is very mixed - and I don't imagine a memory stick,
which describes the physical design IMO, to be an onboard device.

> Problem:
>   When I change card (it was not mounted) da0 device does not detect
>   media change and following mount fails.

Ack.

> Workarounds (I know three at this moment):
>   - kldunload umass; kldload umass - the ugliest, will affect other
> umass devices.
>   - cat /dev/null > /dev/da0  before mount - GEOM hacking 
>     (also I do not like do cat into device with data)

I think this is currently the official way.
It just does what is required to trigger a GEOM rescan.
Everthing else removes the complete device, which is more than
required.

>   - camcontrol detach da0; camcontrol rescan all - requires CAM patch
> 
> So, I am asking about solution, how it is supposed to work, 
> I guess, like with CD, there is should not be special exercises after
> card change.

If I got Poul right then even for the CD case it just works
because of some evilness.

> Probably my card-read is too stupid to send any media change
> notifications, how to test it ?

You should see SCSI messages from the kernel for the first access
after exchanging the media.
But from what I know GEOM doesn't know how to handle exchange
notifications from SCSI devices.
What we IMHO really need is to make the da driver poll the device
for media exchange notifications - and hoope that the drive is
capable to do.
I don't have an idea for drives that don't support notifications.

> Another, probably related question, is there way to detect card
> insertion/removal ?

You can explizitly ask a SCSI device for media and readyness state.

-- 
B.Walter                   BWCT                http://www.bwct.de
[email protected]                                  [email protected]

_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[email protected]"
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.