Date: Tue, 26 Oct 1999 01:09:39 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: imp@village.org (Warner Losh) Cc: mjacob@feral.com, arch@freebsd.org Subject: Re: Racing interrupts Message-ID: <199910260109.SAA21444@usr06.primenet.com> In-Reply-To: <199910251841.MAA42028@harmony.village.org> from "Warner Losh" at Oct 25, 99 12:41:07 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> : This does nothing for threads that were active at the time of the > : interrupt. In this case, either the hardware is sane enough to continue to > : provide some rational non-faulting access (in the case of memory mapping), > : or you have to design a framework such that when the interrupt occurs, and > : the nexus driver now knows how to remap any memory mappings so that a safe > : non-faulting (if nonsensical) access can occur. Then some additional > : mechanism which notifies the actual node driver that things have changed > : will be invoked. > > Hmmm. I could do this, but do not know of any way of mapping I/O > ports sanely. The problem appears to be driver busy waits for bits to > become active. At least that's what it appears to be in the few I've > seen. Most of the problems would be solved if I could detach the > device before unmapping the interrupts, which is the part I needed to > think about... Or rather look hard at the code to see why it is doing > what it is doing and fix it... Certain code won't be fixable like this, e.g. code that does what it does for say a PCMCIA attached floppy disk. Also, I think PIO based (polled) drivers might have a problem with this, whereas they wouldn't with a stack unwind. I think that if the inb/outb code (and bus settle code) was fitted with a lock, and you insisted on grabbing the lock at the nexus, then you potentially sidestep this issue when using a stack unwind approach. Since this is a rather necessary step to achieve better granularity SMP (multiple CPUs in interrupt code simultaneously), it's work that has to be done at some point, anyway. 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?199910260109.SAA21444>