Date: Wed, 27 Oct 1999 01:40:45 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: nate@mt.sri.com Cc: rjesup@wgate.com, tlambert@primenet.com, imp@village.org, arch@freebsd.org Subject: Re: Racing interrupts Message-ID: <199910270140.SAA16700@usr02.primenet.com> In-Reply-To: <199910261525.JAA18872@mt.sri.com> from "Nate Williams" at Oct 26, 99 09:25:03 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > Such as? Of course, just because the MS spec says you should be > > able to pop out the hardware at any time doesn't mean you can't make > > software that says "you MUST shut down the driver before removing the card > > or you may lose all your work", but the problem with that is that it breaks > > the user's expectations, especially if all the other vendors handle it. > > Not to mention that it's a bad idea from a CHI standpoint. > > You're missing the point. What happens if I'm in the middle of a ISR > when the device is popped out? You get a higher priority device eject interrupt, and abort the device ISR before exiting the higher priority interrupt routine. > How do I recognize that it's gone, when I'm expecting the hardware > to respond to some request I've sent it? You get the eject interrupt. > What happens when I'm reading a piece of memory that no longer exists? You don't keep reading, once you get the eject interrupt, because you don't ever return to the code that was doing the reading. For any mmap()'ed device memory (why are you allowing this?) you fault the process. You do not allow memory mapped I/O to a device except in a real or soft ISR with a lower priority than the eject ISR. > > Why can't it be fully eliminated? > > See above, plus previous emails sent on the topic. If that isn't > enough, go read the specification and go think about the problem a > little bit. And if this sounds harsh, it's not meant to, but trying to > explain why it's a problem requires a little bit of experience trying to > fix the problem plus some out of the box thinking about the problem. > > [ > And yes, I've thought about the problem, plus I've coded up the > existing suspend/resume code in FreeBSD to minimize the race, but I've > not eliminated it since I believe it can't be eliminated completely. > ] On a CardBus system, according to the MindShare book, the only really tricky part is that there is a single interrupt that's used. This means that you need to make your interrupt handler reentrant, which is difficult, but not impossible. The way you deal with this is an "enabler". Another alternative, suggested by the book, is to explicitly except faults in protected mode that deal with the cardbus space, and to handle them specially in the fault handler. In the Plug and Play System Architecture, according to that MindShare book, notification from the bridge chip is required to the configuration manager. This is accomplished via an enabler (the enabler in UnixWare, written by Kurt Mahon in 1994, is called "enpic"). The point is that, while I agree it's a lot of work, the problem _is_ resolvable, and that's what FreeBSD should really be striving to achieve. Except with explicitly non-conformant drivers, this problem has been solved on Windows 98 and 2000. > > When I pop a card out, it should _never_ crash. If there's no > > way to avoid the chance of a crash (even 1%), you should not support > > popping of (active) cards out at all. > > That's my point. You can claim to not support it (like Win98 does), but > it doesn't stop people from doing it. If they do it it'll crash, so who > looks bad, the OS or the person? I think he meant support that particular card, with the brain damaged driver that allows it to crash. 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199910270140.SAA16700>