By the way, the Foundry upgrade is really nice.  I really like to snappiness of the site now.

One thing to add, when I detect that a card has been removed, and when I get a UINT_READY request, I answer with a sense
 of:
SK_NOT_RDY, ASC_MEDIA_NOT_RESENT and a ASCQ of 0

Then, when the card is re-inserted, the first time a UNIT_READY request arrives, I issue a sense of:
SK_UNIT_ATN, ASC_MEDIUM_CHANGED and a ASCQ of 0.

This works in that io-blk invalidates its cache, but in order to get the UNIT_READY message to get sent, I have to 
physically access the device.  

Again, I'm hoping there is someway to kick io-blk down this road w/o having to open and read from the device.

Thanks again,
Kevin

I got it figured out.

My peripheral driver thread not only handles the messages from the XPT, but also handles messages (interrupts) from the 
SD hardware.  The problem was that I would get an interrupt that the SD card had been removed and I would then (after 
removing power and clocks from the SD card) call xpt_async( AC_LOST_DEVICE ).

Later, when the interrupt arrived that indicated a card had been inserted, I then initialized the card, applied power 
and clocks, then called xpt_async( AC_FOUND_DEVICES).  

The problem with these two is they expect to run while driver thread is received blocked waiting for messages from the 
XPT.  Well, we can't very well be waiting for messages from the XPT when we're blocked sending messages as if we're the 
XPT, now can we? ;)

Anyway. this is what the xpt_async() functions do, they do stuff that eventually requires an available peripheral driver
 thread to handle things like the inquire message.

So I created a thread that I send a pulse to in order to kick off these functions in one form or another.  It seems to 
work well so far.

So there you have it.  Just in case you always wanted to know but were too afraid to ask.

If someone has more information that can shed more light on this subject, I'm still all ears.  I've learned a lot about 
the XPT/CAM/io-blk, but, boy, there is a lot there.

Anyway, thanks for lending an ear.

Kevin

Well, I'm not out of the woods yet.

Attached is a stack trace of one of the steps xpt_async( AC_FOUND_DEVICES ) takes during it's lifetime.  Notice the <
symbol is not available> between xpt_peripheral_drivers() and xpt_scan_devs().  Something is clobbering the stack.  

My first inclination is to take a close look at what I'm doing in Path Inquery and sd_inquiry to sure I'm not doing 
something bad there, but they are rather simple functions...

Any insight or ideas would be great.

Thanks
Kevin