Date: Tue, 26 Oct 1999 14:08:29 -0600 From: Wes Peters <wes@softweyr.com> To: Bill Fumerola <billf@chc-chimes.com> Cc: Nate Williams <nate@mt.sri.com>, Terry Lambert <tlambert@primenet.com>, imp@village.org, arch@freebsd.org Subject: Re: Racing interrupts Message-ID: <38160A3D.F32AE9E4@softweyr.com> References: <Pine.BSF.4.10.9910261204440.13675-100000@jade.chc-chimes.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Bill Fumerola wrote:
>
> On Mon, 25 Oct 1999, Nate Williams wrote:
>
> > > The system will not crash as a result of this.
> >
> > Not true, it will hang the system. I can show this if more proof is
> > needed on my laptop. There is no software solution that will avoid all
> > problems.
>
> Then you have borked drivers or some other bogon. I can cleanly do all
> of the things Terry says without problem. This alone means it is not only
> possible, but there exists a method to do it properly.
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.
> I'm trying not to add noise because I have no idea of the technical workings
> behind pccard ejection, but lets certainly not discount it just because
> on someone's laptop it doesn't work.
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. ;^)
--
"Where am I, and what am I doing in this handbasket?"
Wes Peters Softweyr LLC
wes@softweyr.com http://softweyr.com/
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?38160A3D.F32AE9E4>