From owner-freebsd-arch Sat Oct 23 23: 8:39 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 AC0AF14DF6 for ; Sat, 23 Oct 1999 23:08:36 -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 IAA06190 for ; Sun, 24 Oct 1999 08:08:35 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id IAA09260 for freebsd-arch@freebsd.org; Sun, 24 Oct 1999 08:08:34 +0200 (MET DST) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 96C5C14DF6 for ; Sat, 23 Oct 1999 23:08:19 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id AAA26549 for ; Sun, 24 Oct 1999 00:08:18 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id AAA34462 for ; Sun, 24 Oct 1999 00:08:47 -0600 (MDT) Message-Id: <199910240608.AAA34462@harmony.village.org> To: arch@freebsd.org Subject: Racing interrupts Date: Sun, 24 Oct 1999 00:08:47 -0600 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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? Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message