From owner-freebsd-arch Tue Oct 26 18:49:10 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 334E814D6F for ; Tue, 26 Oct 1999 18:49:02 -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 DAA29154 for ; Wed, 27 Oct 1999 03:49:01 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id DAA23771 for freebsd-arch@freebsd.org; Wed, 27 Oct 1999 03:49:01 +0200 (MET DST) Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (Postfix) with ESMTP id 3BB2814C2D for ; Tue, 26 Oct 1999 18:48:49 -0700 (PDT) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.9.3/8.9.3) id SAA17519; Tue, 26 Oct 1999 18:48:34 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp01.primenet.com, id smtpdAAAGYaWhI; Tue Oct 26 18:48:30 1999 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id SAA17060; Tue, 26 Oct 1999 18:48:23 -0700 (MST) From: Terry Lambert Message-Id: <199910270148.SAA17060@usr02.primenet.com> Subject: Re: Racing interrupts To: rjesup@wgate.com Date: Wed, 27 Oct 1999 01:48:23 +0000 (GMT) Cc: nate@mt.sri.com, tlambert@primenet.com, imp@village.org, arch@freebsd.org In-Reply-To: from "Randell Jesup" at Oct 26, 99 03:38:20 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Ok, talking to the technical issues: > > [This assumes there's a high-priority interrupt to notify us of > card removal, and the ISR for the interrupt merely sets a flag. It also > assumes that the hardware doesn't go away before the interrupt occurs, > but may be gone by the time the processor handles the interrupt, and that > all pccard ISR's are at a lower interrupt priority than the hardware-is- > gone int.] Invalid assumption, but fixable via virtualization to be virtually true (this is handleable via a reentrancy counter). > First, if you're reading memory that may not exist, check a > flag (whatever) after a series of associated reads, and use that to > know if the reads may have been garbage or not. Yes. > After sending a request to the hardware (probably by writing to > a register), check said flag, and if the hardware is gone, abort the > transaction (to the caller) with an error. Yes. > When a card is removed, wake up all pccard drivers that are in > sleeps waiting on hardware, and let them notice that the hardware is > gone and appropriately error out requests. Yes. > If you're in the middle of an ISR: Check said flag (insertion > state) at appropriate points. In many cases, you merely need check once > or twice I suspect. (I assume writes to removed cards go into the ether, > and reads return something random, which you may need to watch out for - > but often only one check before commiting the results of the interrupt.) > Even if you have to check it a fair number of times, the overhead shouldn't > be large. > > Have I missed something? Some aspect of Unix device drivers I'm > not familiar with? Nate's point about putting the checks into each driver, in particular given that these drivers are shared with less ...transigent hardware, is valid. This is adressibly on the was into the ISR by checking a bit to see if this is a hot swappable device, and eating stack state save overhead, though. The overhead doesn't occur except for the devices where it's necessary to avoid crashes. I'd like to get agreed that it's possible to work around the crappy hardware, to get a roadmap laid down, even if there isn't currently code. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message