Removing CF from IDE Bus

[Guest]

Hello,
We have an XPe system that has some external CompactFlash disks in IDE
adapters. It will be possible (but not advisable) that the user remove the
cards while the system is running. We would like to have the system not go
insane when this happens. We don't really care about doing a hot-swap, we
just want some graceful degradation.

Is it possible to ask windows to rescan the IDE bus before we start doing
operations on those disks?

Is it possible to determine if the card is actually there? We've seen so
far that if Windows thinks there is a drive there, calls to functions like
PathIsDirectory() will still return valid results when the disk is gone.

Thanks!
MJ

 

[Slobodan Brcin \(eMVP\)]

With CM_Request_Device_Eject you can eject any driver that is aware of your
disk and medium. After you succesfuly do this you can remove it from system.

If you need to rescan disks when you add them you can use also one os
SetupApi functions to reenumerate all devices or use devcon for that
purpose.

Regards,

Slobodan

 

[Dave August]

What Slobodan said is quite correct ... but you must somehow realize that
the cards were pulled with out doing an 'eject'... and do the bus resacn so
the system will not think the exist any more..

I know you stated you don't need hotswap but just incase you don't know if
the CF is running in 'TRUE IDE MODE' reinserting it (or another one) won't
work.. it's all based on how the card detects 'true IDE mode' (and it's
funky).

Also I have seen CF cards that go bonkers when you remove them *WHILE*
windows is writing to them... sooo in the long run this isn't a good idea...

Dave

 

[Slobodan Brcin \(eMVP\)]

Hi Dave,

If you eject/remove driver responsible for IDE channel that CF reader is
connected to. This would remove CF reader from windows awareness. Then if
you insert new CF and reenumerate drivers it should show up.

Regards,
Slobodan

 

[Dave August]

Hi ya Slobodan.. LTNC..

Just to clarify, I don't think what you say will work... This has nothing to
do with XP Drivers but has to do with how th CF card is electricaly placed
into 'TRUE IDE MODE'.. To get a CF card into 'TRUE IDE MODE' you ground the
*OE signal and power the card up, and use the *IORD/*IOWR signals to
communicate with it... the problem assises when you insert a CF card into a
connector that is powered... The power is applied to the CF before the *OE
line is grounded.. sooo... the card powers up in PCMCIA mode.. :-(... I've
developed several pieces of hardware the used single chip micros and a CF
and I can tell you for sure this is what happens...

Dave

 

[Slobodan Brcin \(eMVP\)]

Hi Dave,

I never tried IDE CF reader (only USB CF readers) so you are probably right.
I have spent too much time playing with devices that can power down that I
instinctively thought that IDE CF reader will do the same.

BTW:
What happens if you connect CF and then reboot computer without powering it
down? Will it work?

Regards,
Slobodan

 

[Dave August]

Slobodan

Nope won't work.. reboot does nothing special, even the IDE bus reset won't
make it wake up correctly. It's gotta be a power cycle with *OE low... It's
a real PITA... FWIW the PCMCIA mode looks to software *exactly* like TRUE
IDE if you keep all the upper address bits low, but *OE and *WE don't have
the same timing as *IORD/*IOWR and there are few other subtle electrical
differences.. IMHO the they really screwed up the CF card spec in this
respect..

Dave

 

[Slobodan Brcin \(eMVP\)]

Dave,

Thanks for info. I guess that I won't be using it some time soon (ever).

Regards,
Slobodan

 

[Guest]

Dave and Slobodan,
I would like to reiterate that we're not worried about rebooting, or the
electrical specs of the CF card, but we're worried that the user is likely to
remove the card during operation. So would it be sufficient to run a rescan
of the IDE bus? And if so, how can I use devcon to do that?

Thanks!
MJ

 

[Slobodan Brcin \(eMVP\)]

MJ,

Oh we went away from toppic :-(

1. Make sure that disk is marder as removable. Or at least that all caching
is disabled like on removable disk.
2. Try IOCTL_STORAGE_CHECK_VERIFY
3. Use IOCTL_STORAGE_SET_HOTPLUG_INFO.
4. I don't know if it will help you with something but look at
IOCTL_STORAGE_LOAD_MEDIA2 and IOCTL_STORAGE_EJECTION_CONTROL,
IOCTL_STORAGE_EJECT_MEDIA
5. Have you tried RAW read from beggining of the disk? What happen then?
6. What happen if you try to browse it?

Regards,
Slobodan

 

[Dave August]

MJ

I'll add to what Slobodan has said.

The way to dismount a drive is to use these IO controls in this order
FSCTL_LOCK_VOLUME
FSCTL_DISMOUNT_VOLUME
FSCTL_UNLOCK_VOLUME

This is basicaly what the system does when it formats a disk.
After the unlock, any calls that referance the device will cause the system
to try and remount it.

Go read the documentation on them and see if they will help you.

These calls play somewhat in to what Sloboban suggested, you have to get an
hFile to the device to use them. Thats the same handle you'd need for raw
reads. In case you don't know you get that with a CreateFile call similar
to this.
hFile=CreateFile(\\\\.\\C:,GENERIC_READ | GENERIC_WRITE, FILE_SHARE_READ |
FILE_SHARE_WRITE ,NULL,OPEN_EXISTING,FILE_ATTRIBUTE_NORMAL,NULL);

Dave

 

[Guest]

Thanks Slobodan,
Some of our disks will be marked as fixed, but I think we can arrange to
make those particular ones removable.

If you try a raw read from the disk, our software locks up and also locks up
XPe.

If you try to explore the file through explorer, explorer hangs and never
comes back.

 

[Slobodan Brcin \(eMVP\)]

What about current disk that you use is it removable or fixed?

I was afraid that this freeze might happen but are you sure that you
accessed disk?
CreateFile(\\\\.\\PHYSICALDRIVEX", .... ?

Anyhow on that handle you should use DeviceIoControl with codes that I gave
you.

Also to simplify diagnosis of what failed make sure that you have at least
following :
First sector on disk filled with zeroes so that there are no partititons and
filesystems mounted.
Now when you pull device out we will know whether infrastructure can handle
disk removal or not.

Regards,
Slobodan

 

[Slobodan Brcin \(eMVP\)]

Hi Dave,

What you have said goes for FS driver control only and has nothing to do
with disks. (Well on removable disks volume letter can represent disk driver
itself in some cases).
He should open lower "disk driver" handle since I suggested him in second
post to zero-out first sector on disk, after he reboot with this disk
connected there won't be any need for dismounting FS from that disk.

Regards,
Slobodan

PS: If he has fixed disk he could have much more than one volume on that
disk. So it is a little pain in .... to match volumes to specific disk.

 

[Dave August]

Slobodan,

Don't want to argue but this will do exactly what he want's. It'll tell the
O.S. that the device no longer exisit. Any filesystem ops will fail and not
hang. He's not dealing with a fixed disk here, remember this thread started
about users removing a CF card that technically can't have more than 1
partition if it's marked as a removable.

Dave

 

[KM]

MJ,

Dave and Slobodan,
I would like to reiterate that we're not worried about rebooting, or the
electrical specs of the CF card, but we're worried that the user is likely to
remove the card during operation. So would it be sufficient to run a rescan
of the IDE bus? And if so, how can I use devcon to do that?

"devcon rescan"?
http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q311272
http://msdn.microsoft.com/library/d..._576b9c3f-0c84-47ef-92b0-2d2957faaa48.xml.asp

Btw.. even "diskpart rescan" may be helpful to rescan all I/O buses and cause any new disks that have been added to the computer to
be discovered.
http://support.microsoft.com/default.aspx?scid=kb;en-us;300415

 

[Slobodan Brcin \(eMVP\)]

Dave,

We do not argue here but want to get to the bottom of the things (at least I
hope so).

So first on IDE bus of significant drivers we have:

PCI Bus (pci.sys)
- Specific storage controller driver (intelide.sys, pciidex.sys, atapi.sys)
-- Primary IDE Channel driver (atapi.sys) same goes for Secondary IDE
Channel
--- Disk Driver (disk.sys/classpnp.sys)
Above this point things get little confusing and you can have:
partmgr.sys, dmio.sys, ftdisk.sys, ewf.sys, etc
Above you have can have some number of FAT, NTFS filesystems active or you
don't need to have FS at all. (On mediums marked as removable, disk.sys will
expose only first partition in MBR table so you will see one partition
only. )

Regardless of removable or fixed medium \\.\X: will always mean FS and or
partition driver access and it will be bound to partition limits described
by MBR (if present).

When you send IOCTL to certain driver that you can get handle on (of course)
it will be examined by that driver and send to lower driver in case that it
is not handled by that driver and eventually it will go up to bus driver (I
do not mean PCI bus driver)

Few info about FSCTL:
1. FSCTL codes talk to partition/filesystem driver and that is it these
drivers are the highest drivers in the stack and they do not propagate to
disk and storage drivers. So they can't influence how hardware is working
and device along with all other drivers will remain present. (Only FS driver
is temporarily closed).
2. As long as you keep open handle to any disk volume it is not smart thing
to remove hardware since drivers might not be able to do 100% proper
clean-up.
3. You should release your handle before you remove device. But something
might access FS and it will mount again.

So to get to point.
CM_Request_Device_Eject will remove all your driver from memory and dismount
all that need to be dismounted. And you should target specific Primary IDE
Channel driver to tear down whole stack above it.

Or very hard alternative as you suggested.
- Find and lock/eject all disk volumes. (One in your case)
- Tell to storage driver to unmount medium.
- Close all handles that you hold.

Storage will stay in unmounted state but you will see and be able to open
all volumes again but nothing can't talk with medium any more unless you
bring mount medium itself bask trough IOCTL functions.

Huh there is too much more to be written for this to make any sense, I give
up :-(

Regards,
Slobodan

 

[Dave August]

Slobodan,

We are both essentially saying the same thing...

But my way only requires the LOGICAL drive \\.\X:

That's what the OP has.. he is opening and writing files to it...You want
him to get a PHYSICAL device, as you have said (and know) much harder to map
LOGICAL drive to PHYSICAL device.

I know what I've said works .. I've done it..

Don't forget in his example someone has already removed the CF card.. he
just want to invalidate the filesystem.

Dave

 

[Slobodan Brcin \(eMVP\)]

Hi Dave,

Any comment on MJ statement: "If you try a raw read from the disk, our
software locks up and also locks up XPe."
Now if we assume that he know how to read from disk by using disk driver how
do you explain what exactly locked up the system? There are no mention there
of FS and FS drivers he goes around and test disk.sys driver. In case that
disk.sys driver fails FS dismount will fail because of same reason. (some
data must be written trough disk driver when you close FS).

Don't forget in his example someone has already removed the CF card.. he
just want to invalidate the filesystem.

I never forgot this. Disk.sys driver is responsible for CF card. So if you
manage to shut him down all filesystems, volumes etc will be removed as
well.

I know what I've said works .. I've done it..

I do not doubt that you have. Also it might work on few different devices
and CF readers, but are you 100% sure that it will work always.

Regards,
Slobodan

PS:
If you are interested that we try to figure out why CF can/can't be hot
swapped on IDE bus please let me know. We can try to figure it out online in
thread: "CF HOT SWAP" or offline trough email.
What specs say that can be done or can't be done is often subject to
interpretation and default behavior and does not reflect real word
conditions. Please don't just say me you tried one CF reader and decided
that this is true and that it is how it works without putting a finght on
it.

 

[Dave August]

Slobodan,

I KNOW why CF on IDE can't be hot swapped. And am %100 sure it's that way
with ALL CF cards. I know this because I have designed single chip micro
based hardware for embeded control, that used CF.

I will try and explain here in a bit more detail.

CF Cards are multi-modal... The can operate electrically in 2 basic modes,
with a minor extension in one of those modes.

The 2 modes are 'TRUE IDE' and 'PCMCIA' mode. The basic electrical interface
to a CF is PCMCIA. There are 12 address lines and 4 control signals used to
strobe data in and out of the CF card. The 4 signals are *OE (output
enable), *WE (write enable), *IORD (I/O Read), *IOWR (I/O Write). The
control signals are negative logic, active low and are normaly high and
actualy have weak pullups in the hardware.. In PCMCIA mode, all 4 control
signals and all 12 address bits are used. The 'IO space' uses *IORD, and
*IOWR and allows access to the registers that select sectors and read/write
control information and are EXACTLY the same registers used in IDE mode, you
can even do sequential access just like IDE. There are also extra registers
not present in the IDE mode for security, error analisis and other
functions. All 12 Address bits are used but the regester space rolls over
every 16 addresses. *OE and *WE are used with the full 12bit address range
to allow random access to the selected memory, note this is an 8K address
range. In PCMCIA mode several of the other control signals that are used in
TRUE IDE mode have different meaning, including RESET. RESET becomes active
HIGH in PCMCIA mode and is Active LOW in TRUE IDE mode. There is also no
concept of PDIAG or MASTER/SLAVE in PCMCIA mode and those lines are either
ignored or have some other meaning.

To place a CF card in TRUE IDE mode, you hardwire *OE to ground. When the CF
card is powered up if *OE is LOW the card goes into TRUE IDE. it will IGNORE
*WE and essentially ignore *OE and only use the 3 lowest address bit in
conjunction with *IORD and *IOWR. The extra registers will not be
accessable.

The CF card connector is designed to apply power BEFORE any of the signal
lines are connected, look at one and you will see several pins are longer,
those are the power and ground pins... Therefore it is IMPOSSIBLE to plugin
a CF card and have *OE grounded when the card powers up and so it is
therefore IMPOSSIBLE to hot plug a CF card and have it run in TRUE IDE mode.
This is all laid out in the CF Spec.

Dave