BACKGROUND:
I’m working on a medical device that will use a SanDisk ATA Flash Card as a
means to copy info to/from a laptop (basically a high capacity replacement
for a floppy).
I’m able to achieve this by having PcmciaLaunch run a program that does the
following:
(Card insertion - PcmciaLaunch executes my program - my program does the
following:)
Fsys.ata -aXXX -iY -nskd -NskD
mount -p /dev/skd0
Dosfsys d=/dev/skd0t4
(Card is now accessable as /dos/d)
(Card removed - PcmciaLaunch signals my program which performs the following
cleanup:)
Dosfsys -x
umount /dev/skd0
rm /dev/skd0
THE PROBLEM:
This works fine as long as the card is not removed at an ‘inappropriate
time’. If it is then QNX locks up. Not even any cursor movement - nothing.
This ‘inappropriate time’ appears to be the window from when the card is
removed until the clean up is done. I can force this to happen by disabling
the clean up when the card is removed. Then I simply remove the card and
attempt an ‘ls /dos/d’ command - immediate lockup occurs.
I realize that the user shouldn’t remove the card at an inappropriate time,
but if it can happen then it will happen. Also this is a medical device and
needs to be robust in every aspect of its functionality - QNX locking up is
not robust.
My expectation for how robust the PCMCIA cards should be are set by the
Floppy drive - I am unable to lock up the system by pulling the floppy at
any time. (Also - I seem to be able to pull the PCMCIA card from a laptop at
any time and no lock-ups occur.)
I’ve searched the newsgroups and knowledge base for help on this problem -
but have not found any.
Note that I can also use Fsys.eide and Fsys.vpn50 in place of Fsys.ata - but
the lock-ups still occur. The params to Fsys.eide and Fsys.vpn50 are
formatted differently than to Fsys.ata of course. Also - I’ve tried
Efsys.pcmcia but have not figured out how to use it - very little info in
documentation/newsgroups/knowledge-base regarding Efsys - perhaps this is
only to be used on linear flash devices? Not ATA style?.
Any help is greatly appreciated,
Ed Theobald
Revis & Associates
edtheobald@starband.net
Ed Theobald <edtheobald@starband.net> wrote:
: I’m working on a medical device that will use a SanDisk ATA Flash Card as
: a means to copy info to/from a laptop (basically a high capacity
: replacement for a floppy).
Firstly, ATA flash cards in a Type II PCMCIA slot are NOT robust. Period.
Because it is flash, there is a non-trivial erase/write cycle, and if
power is interrupted during this process the card can be corrupted. This
is due to the lack of an interlock mechanism to prevent/notify about
ejection requests during active writes. Refer to the “SanDisk Product
Application Notes” in their “Technical Reference Guide” (80-36-00034).
Secondly, Dosfsys is intended as a convenience file transfer utility,
and not a robust active filesystem. It internally caches the FAT with
no attempt to keep the ondisk copy up-to-date (except when it is
terminated, but since PCMCIA notification occurs during/after card
ejection, it is too late to perform the writes, and in fact may cause
corruption by initiating an erase cycle that has no power to complete).
Is it possible to use Fatfsys instead, you can give it the “-m sync”
option to force synchronous writes, which has the potential for being
more robust (and just “slay” it in the cleanup to prevent more writes).
John, thanks for your reply:
Let me expand on what I consider to be the problem:
I have no problem with possible PCMCIA file corruption in the event that the
user ejects the card when they shouldn’t.
The problem is that QNX locks up! The medical device itself is left %100
inoperable. (The FDA and TUV tend to frown on such behavior in a medical
device! 
)
The documention states that Fsys.eide should be used for removable media, so
I’m guessing that this may be the one to use. However, QNX locks up when
using Fsys.eide as well.
Any help with the issue of QNX locking up? My expectation is that Fsys or
some filesystem layer will sense the failure to access the media and return
a failure status. This is what appears to take place when a Floppy is
removed.
I appreciate any help.
Ed Theobald
Revis & Associates
edtheobald@starband.net
P.S. - I was unaware of the existance of Fatfsys! Thanks for the pointer -
I’ll download the update and give it a try. Nonetheless - I believe the QNX
locking up problem still warrants attention.
Also - I’m starting another QNX based medical device project - it will be
Neutrino based. Currently the customer requirements state that a PCMCIA card
will be used for exporting files as well! This problem may rise again under
Neutrino!.
“John Garvey” <jgarvey@qnx.com> wrote in message
news:9dbj1m$hlg$1@nntp.qnx.com…
Ed Theobald <> edtheobald@starband.net> > wrote:
: I’m working on a medical device that will use a SanDisk ATA Flash Card
as
: a means to copy info to/from a laptop (basically a high capacity
: replacement for a floppy).
Firstly, ATA flash cards in a Type II PCMCIA slot are NOT robust. Period.
Because it is flash, there is a non-trivial erase/write cycle, and if
power is interrupted during this process the card can be corrupted. This
is due to the lack of an interlock mechanism to prevent/notify about
ejection requests during active writes. Refer to the “SanDisk Product
Application Notes” in their “Technical Reference Guide” (80-36-00034).
Secondly, Dosfsys is intended as a convenience file transfer utility,
and not a robust active filesystem. It internally caches the FAT with
no attempt to keep the ondisk copy up-to-date (except when it is
terminated, but since PCMCIA notification occurs during/after card
ejection, it is too late to perform the writes, and in fact may cause
corruption by initiating an erase cycle that has no power to complete).
Is it possible to use Fatfsys instead, you can give it the “-m sync”
option to force synchronous writes, which has the potential for being
more robust (and just “slay” it in the cleanup to prevent more writes).
Previously, Ed Theobald wrote in qdn.public.qnx4:
John, thanks for your reply:
Let me expand on what I consider to be the problem:
I have no problem with possible PCMCIA file corruption in the event that the
user ejects the card when they shouldn’t.
The problem is that QNX locks up! The medical device itself is left %100
inoperable. (The FDA and TUV tend to frown on such behavior in a medical
device! > > )
The documention states that Fsys.eide should be used for removable media, so
I’m guessing that this may be the one to use. However, QNX locks up when
using Fsys.eide as well.
Any help with the issue of QNX locking up? My expectation is that Fsys or
some filesystem layer will sense the failure to access the media and return
a failure status. This is what appears to take place when a Floppy is
removed.
I appreciate any help.
The problem here is one of interrupts! If the disk driver is still running
and you eject the card, the driver could receive an interrupt, but when it
reads the status to find out what interrupt it received, the card has gone!
The way to do this is not to slay the driver after the card has been removed,
but before. You will have to devise some way to unmount the drive and slay
the driver before removing the card. This would require operator intervention,
I guess.
Ed Theobald
Revis & Associates
edtheobald@starband.net
P.S. - I was unaware of the existance of Fatfsys! Thanks for the pointer -
I’ll download the update and give it a try. Nonetheless - I believe the QNX
locking up problem still warrants attention.
Also - I’m starting another QNX based medical device project - it will be
Neutrino based. Currently the customer requirements state that a PCMCIA card
will be used for exporting files as well! This problem may rise again under
Neutrino!.
“John Garvey” <> jgarvey@qnx.com> > wrote in message
news:9dbj1m$hlg$> 1@nntp.qnx.com> …
Ed Theobald <> edtheobald@starband.net> > wrote:
: I’m working on a medical device that will use a SanDisk ATA Flash Card
as
: a means to copy info to/from a laptop (basically a high capacity
: replacement for a floppy).
Firstly, ATA flash cards in a Type II PCMCIA slot are NOT robust. Period.
Because it is flash, there is a non-trivial erase/write cycle, and if
power is interrupted during this process the card can be corrupted. This
is due to the lack of an interlock mechanism to prevent/notify about
ejection requests during active writes. Refer to the “SanDisk Product
Application Notes” in their “Technical Reference Guide” (80-36-00034).
Secondly, Dosfsys is intended as a convenience file transfer utility,
and not a robust active filesystem. It internally caches the FAT with
no attempt to keep the ondisk copy up-to-date (except when it is
terminated, but since PCMCIA notification occurs during/after card
ejection, it is too late to perform the writes, and in fact may cause
corruption by initiating an erase cycle that has no power to complete).
Is it possible to use Fatfsys instead, you can give it the “-m sync”
option to force synchronous writes, which has the potential for being
more robust (and just “slay” it in the cleanup to prevent more writes).
\
In article <Voyager.010509132337.1054A@node90.ott.qnx.com>,
hsbrown@qnx.com says…
Previously, Ed Theobald wrote in qdn.public.qnx4:
John, thanks for your reply:
Let me expand on what I consider to be the problem:
I have no problem with possible PCMCIA file corruption in the event that the
user ejects the card when they shouldn’t.
The problem is that QNX locks up! The medical device itself is left %100
inoperable. (The FDA and TUV tend to frown on such behavior in a medical
device! > > )
The documention states that Fsys.eide should be used for removable media, so
I’m guessing that this may be the one to use. However, QNX locks up when
using Fsys.eide as well.
Any help with the issue of QNX locking up? My expectation is that Fsys or
some filesystem layer will sense the failure to access the media and return
a failure status. This is what appears to take place when a Floppy is
removed.
I appreciate any help.
The problem here is one of interrupts! If the disk driver is still running
and you eject the card, the driver could receive an interrupt, but when it
reads the status to find out what interrupt it received, the card has gone!
The way to do this is not to slay the driver after the card has been removed,
but before. You will have to devise some way to unmount the drive and slay
the driver before removing the card. This would require operator intervention,
I guess.
Just a suggestion for a possible software fix…
When the interrupt comes in, apply some sanity check to the operation
that reads the status. If the read fails, or the sanity check fails, then
take the appropriate action to /shut down/release/or whatever is
appropriate/ the driver.
(e.g. It probably is impossible (or highly unlikely) to get “all ones”
from the interrupt status register if the hardware is present and
functioning correctly - but that is possibly what you will get if the
hardware has gone missing. Assuming you do not get any other error
indication.)
Ed Theobald
Revis & Associates
edtheobald@starband.net
P.S. - I was unaware of the existance of Fatfsys! Thanks for the pointer -
I’ll download the update and give it a try. Nonetheless - I believe the QNX
locking up problem still warrants attention.
Also - I’m starting another QNX based medical device project - it will be
Neutrino based. Currently the customer requirements state that a PCMCIA card
will be used for exporting files as well! This problem may rise again under
Neutrino!.
“John Garvey” <> jgarvey@qnx.com> > wrote in message
news:9dbj1m$hlg$> 1@nntp.qnx.com> …
Ed Theobald <> edtheobald@starband.net> > wrote:
: I’m working on a medical device that will use a SanDisk ATA Flash Card
as
: a means to copy info to/from a laptop (basically a high capacity
: replacement for a floppy).
Firstly, ATA flash cards in a Type II PCMCIA slot are NOT robust. Period.
Because it is flash, there is a non-trivial erase/write cycle, and if
power is interrupted during this process the card can be corrupted. This
is due to the lack of an interlock mechanism to prevent/notify about
ejection requests during active writes. Refer to the “SanDisk Product
Application Notes” in their “Technical Reference Guide” (80-36-00034).
Secondly, Dosfsys is intended as a convenience file transfer utility,
and not a robust active filesystem. It internally caches the FAT with
no attempt to keep the ondisk copy up-to-date (except when it is
terminated, but since PCMCIA notification occurs during/after card
ejection, it is too late to perform the writes, and in fact may cause
corruption by initiating an erase cycle that has no power to complete).
Is it possible to use Fatfsys instead, you can give it the “-m sync”
option to force synchronous writes, which has the potential for being
more robust (and just “slay” it in the cleanup to prevent more writes).
\
–
Stephen Munnings
Software Developer
Corman Technologies Inc.
Stephen Munnings <steve@cormantech.com> wrote:
: In article <Voyager.010509132337.1054A@node90.ott.qnx.com>,
: hsbrown@qnx.com says…
:> The problem here is one of interrupts! If the disk driver is still running
: Just a suggestion for a possible software fix…
: When the interrupt comes in, apply some sanity check to the operation
: that reads the status. If the read fails, or the sanity check fails, then
I don’t think that there are any such issues within the Fsys.eide driver.
At key points it interprets 0xFF on the status register as meaning that
a PCMCIA card has been ejected. At the places in which it doesn’t do
this, worst case is that it may loop for 15ms looking for !ATA_BUSY.
Multiply by 6x CAM-layer retries, this is 1 second of potentially
sluggish disk IO. What do you mean by “system locks ups”? What can
be done from a high-priority shell? What happens if your eject the card
without Dosfsys? What happens if you substitute Fatfsys instead?
What do you mean by “system locks ups”?
By ‘system locks up’ I mean “I can’t even move the cursor with the mouse”.
No keyboard response. Requires a hard re-boot.
What happens if your eject the card without Dosfsys?
If I re-format an ATA flash card as a QNX partition, and perform the
following commands:
(Insert card)
Fsys.eide eide -aXXX -iY fsys -nskc -NskC
mount -p /dev/skc0
mount /dev/skc0t77 /pcm_c
(Eject card)
Try “ls /pcm_c”
System locks up - never to return.
Note: As far as I know, I need to access the card (in this case, via ‘ls’)
in order to get the system to lock up.
What happens if you substitute Fatfsys instead?
Haven’t tried yet. Hopefully will have access to hardware later today.
Other Info:
-We are running version 4.23(d?). I need to install the upgrade to 4.25 to
get Fatfsys.
-The pcmcia controller chip on our hardware is the Cirrus Logic PD6722.
- Our product used 2 PCMCIA slots - one as a DOS slot for tranfering to/from
PC. The other is formatted as a t77 partition and is used to store the
running state of the machine (this is written to periodically - without
prompting from the user). In case of failure this card is transfered to
another device so that it can be restored to the same state as the initial
device.
“John Garvey” <jgarvey@qnx.com> wrote in message
news:9dd437$fa2$1@nntp.qnx.com…
Stephen Munnings <> steve@cormantech.com> > wrote:
: In article <> Voyager.010509132337.1054A@node90.ott.qnx.com> >,
: > hsbrown@qnx.com > says…
:> The problem here is one of interrupts! If the disk driver is still
running
: Just a suggestion for a possible software fix…
: When the interrupt comes in, apply some sanity check to the operation
: that reads the status. If the read fails, or the sanity check fails,
then
I don’t think that there are any such issues within the Fsys.eide driver.
At key points it interprets 0xFF on the status register as meaning that
a PCMCIA card has been ejected. At the places in which it doesn’t do
this, worst case is that it may loop for 15ms looking for !ATA_BUSY.
Multiply by 6x CAM-layer retries, this is 1 second of potentially
sluggish disk IO. What do you mean by “system locks ups”? What can
be done from a high-priority shell? What happens if your eject the card
without Dosfsys? What happens if you substitute Fatfsys instead?
Ed Theobald <edtheobald@starband.net> wrote:
:>>> What do you mean by “system locks ups”?
: By ‘system locks up’ I mean “I can’t even move the cursor with the mouse”.
: No keyboard response. Requires a hard re-boot.
Wow - it looks like you’re the first person to try this. There is a bug
in Fsys.eide with handling such card removals (it will run ready at pri22
trying to acknowledge to the controller that it has seen the media removed).
You should be able to kill it over the net or from a high-priority text
shell though, but that leaves Fsys inconsistent. There is also a problem
with Fsys if you attempt to umount a removed device (it will EBADFSYS
causing a later EBUSY on the raw device umount/rm attempt).
So, you will need new Fsys and Fsys.eide components.
Or, you may be able to work around it with your existing versions by
running your PcmciaLaunch script at a >22 priority and using a second
Fsys solely for the PCMCIA. Use “Fsys -Nqnx/fsysPCMCIA” and
“Fsys.eide fsys -Fqnx/fsysPCMCIA” to set this up at insertion and then
just slay everything (no unmounting) at the removal at high priority.
Note that there is a rare Fsys bug writing to removable devices (such as
PCMCIA ATA) in versions prior to 4.24V, and the FAT caching issues of
Dosfsys I mentioned earlier. For this reasons a 4.25 upgrade may be
considered desirable …
That was great news John! Thanks a million.
I’ll try the work-around and try an upgrade to 4.25 as soon as I have access
to the hardware.
So … how and when can I get my grubby little hands on a fixed Fsys and
Fsys.eide?
Ed Theobald
Minnetronix, Inc.
edtheobald@starband.net
“John Garvey” <jgarvey@qnx.com> wrote in message
news:9deurk$kd8$1@nntp.qnx.com…
Ed Theobald <> edtheobald@starband.net> > wrote:
:>>> What do you mean by “system locks ups”?
: By ‘system locks up’ I mean “I can’t even move the cursor with the
mouse”.
: No keyboard response. Requires a hard re-boot.
Wow - it looks like you’re the first person to try this. There is a bug
in Fsys.eide with handling such card removals (it will run ready at pri22
trying to acknowledge to the controller that it has seen the media
removed).
You should be able to kill it over the net or from a high-priority text
shell though, but that leaves Fsys inconsistent. There is also a problem
with Fsys if you attempt to umount a removed device (it will EBADFSYS
causing a later EBUSY on the raw device umount/rm attempt).
So, you will need new Fsys and Fsys.eide components.
Or, you may be able to work around it with your existing versions by
running your PcmciaLaunch script at a >22 priority and using a second
Fsys solely for the PCMCIA. Use “Fsys -Nqnx/fsysPCMCIA” and
“Fsys.eide fsys -Fqnx/fsysPCMCIA” to set this up at insertion and then
just slay everything (no unmounting) at the removal at high priority.
Note that there is a rare Fsys bug writing to removable devices (such as
PCMCIA ATA) in versions prior to 4.24V, and the FAT caching issues of
Dosfsys I mentioned earlier. For this reasons a 4.25 upgrade may be
considered desirable …