Date: Sun, 24 Oct 1999 01:06:35 -0600 From: Wes Peters <wes@softweyr.com> To: Warner Losh <imp@village.org> Cc: arch@freebsd.org Subject: Re: Racing interrupts Message-ID: <3812AFFB.B028C64D@softweyr.com> References: <199910240608.AAA34462@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Warner Losh wrote:
>
> Consider the following situation. There is a driver talking to a
> device. An unmasked interrupt happens and the device is now gone.
> How does the driver know to stop what it is doing and respond to this
> disappearance in a sane way?
>
> This sort of situation comes up in the pccard code. When someone
> ejects the card, an interrupt fires. If I were to remove the device
> from the tree in the interrupt handler, I can invalidate the softc
> that the driver is still using by freeing it. At that point the
> driver is running out of freed memory and all bets are off.
>
> I can schedule a timeout to happen in 0 clock ticks so that it is then
> "safe" to remove the device, but the hardware is either gone or very
> close to being gone when the first interrupt happens, so we've moved
> the problem from memory corruption to a hardware hang.
>
> It would be nice if there was some way to ref/unref the use of softc
> so I could remove the device right away, but defer the actual removal
> of the device and softc until the last deref of softc. This strikes
> me as a major PITA and may still result in a hardware hang.
>
> It is my understanding that the pccard hardware still still exist for
> a period of time after the card is ejected (since it takes some period
> of time to move from the pins that caused the interrupt to the
> power/control/data pins being disabled). I don't know if this is
> true, or if true what the period of time is.
>
> What I really want is a kernel signal mechanism which will start a
> rundown of the driver thread which is not allowed to touch hardware,
> but can only free resources used by the driver. We have lots of tight
> loops in drivers in the kernel and it seems unwise to pessimize those
> so that this race can be dealt with...
>
> Comments?
This has recently been dealt with by the Linux group at Motorola, adding
support for Compact PCI. I don't know if it's been incorporated into
the Linux kernel yet, but I can find out. If not, I'm pretty certain I
can get you a look at the code if it will be helpful at all.
--
"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?3812AFFB.B028C64D>