From owner-freebsd-arch Sun Oct 24 0: 6:50 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 742AB1505F for ; Sun, 24 Oct 1999 00:06:47 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id JAA06533 for ; Sun, 24 Oct 1999 09:06:46 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id JAA09434 for freebsd-arch@freebsd.org; Sun, 24 Oct 1999 09:06:46 +0200 (MET DST) Received: from mail.xmission.com (mail.xmission.com [198.60.22.22]) by hub.freebsd.org (Postfix) with ESMTP id 23B561508F for ; Sun, 24 Oct 1999 00:06:38 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from [204.68.178.39] (helo=softweyr.com) by mail.xmission.com with esmtp (Exim 2.12 #2) id 11fHjg-0004HC-00; Sun, 24 Oct 1999 01:06:37 -0600 Message-ID: <3812AFFB.B028C64D@softweyr.com> Date: Sun, 24 Oct 1999 01:06:35 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Warner Losh Cc: arch@freebsd.org Subject: Re: Racing interrupts References: <199910240608.AAA34462@harmony.village.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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