Reattach/redetect allways connected umass device - is it
possible ?
Poul-Henning Kamp
phk at phk.freebsd.dk
Mon Mar 28 05:32:49 PST 2005
In message <1112015844.1022.44.camel at localhost>, Vladimir Grebenschikov writes:
>÷ ÐÎ, 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 <20050328114633.GZ14532 at cicely12.cicely.de>, 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.
>How it is supposed to work in this case ?
That's a very good question.
The original intent in GEOM was that the geom instance would represent
the media while the drive (if separate for the media) would have
another access mechanism.
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.
This works with the broken-by-design CDrom ioctls etc.
What is missing is to tickle GEOM when the media is inserted so
that the tasting takes place.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
More information about the freebsd-mobile
mailing list