Bill Fumerola wrote:

Try this: hang a disk drive off a SlimSCSI and start something I/O intensive on the drive, like a disk benchmark write test. Now pop the SCSI card out during the I/O.

First you should know PCMCIA was designed with memory cards in mind.

The ejection mechanism tells you the card is going away by providing an interrupt. It's the same interrupt that all other notifications from the card use. It does this by having a short pin on the connector; when the short pin becomes detached the PCMCIA Controller in your system generates the interrupt. You have some small amount of time before the rest of the pins become detached in which you can still communicate with the card, but this time is not fixed, it will depend on the card, the ejector, and on how hard the user pushes the ejector button.

If you've just begun to process another interrupt from the card, such as I/O ready or I/O complete, you won't be able to process the ejection interrupt until your current interrupt completes, but what happens if the card goes away before your current interrupt completes? Then you're attempting to read and write I/O ports and/or memory locations that no longer exist, but you don't know they no longer exist.

The "right" thing to do would be for the hardware controller to generate a bus error if you try to write registers or memory addresses for a card that has gone away, but it doesn't.

You're also left with questions about what to do with outstanding I/O requests when the device goes away, and how to handle the open references to the device.

None of the design is simple, and it is complicated by the fact that PCMCIA wasn't developed for I/O devices. If you want to jump in and help, I'm sure everyone involved would welcome the help. Buy the PCMCIA and CardBus architecture books, familiarize yourself with the code, and ponder how to handle these and other stick issues as cleanly as possible. Submit working patches, ask intelligent questions, and give intelligent answers. You know, kind of like working on FreeBSD. ;^)

To Unsubscribe: send mail to majo...@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message