Date: Thu, 20 Jul 2000 01:15:08 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Greg Lehey <grog@lemis.com> Cc: Mike Smith <msmith@FreeBSD.ORG>, Alfred Perlstein <bright@wintelcom.net>, arch@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: Tidying up the interrupt registration process Message-ID: <Pine.BSF.4.21.0007200023590.6986-100000@besplex.bde.org> In-Reply-To: <20000719140707.K12072@wantadilla.lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 19 Jul 2000, Greg Lehey wrote: > On Tuesday, 18 July 2000 at 21:15:53 -0700, Mike Smith wrote: > >> * Mike Smith <msmith@FreeBSD.ORG> [000718 20:55] wrote: > >>> > >>> Sharing a 'fast' interrupt completely defeats the point of making it > >>> 'fast'. You should not be able to register a 'fast' handler on any > >>> source with anything else attached, nor anything else on a source that > >>> has a 'fast' handler already registered. Yes, this does impose some > >>> configuration constraints on the system, but there are few viable > >>> alternatives. Not quite. Attaching multiple fast interrupt handlers to the same irq is not much different from attaching them to different irqs. The handlers should be executed serially in the !SMP case and on different CPUs (serially per CPU) in the SMP case. This is currently not implemented. Sharing the irq is only undesirable (in the all-fast case) because it adds overheads for polling all the devices. Attaching a mixture of fast and normal handlers to the same irq seems to be impossible to implement. If interrupts are edge triggered, then we don't need to touch the PIC masks currently do in the i386 !SMP case (I'm not sure about other cases), but we won't see new interrupts for fast devices on the same irq while we are handling normal interrupts. This defeats the point of using fast interrupts. If interrupts are level triggered, then we must set the PIC masks to prevent endless interrupts, and again we won't see fast interrupts whule handling normal ones. > >> Just wondering, could a device fall back to non-fast mode if the > >> hardware forced this sort of situation but still complain about it? > > > > You don't typically bother requesting a 'fast' interrupt unless you > > really need it. This decision would have to be left up to the > > device driver - some might be OK accepting the tradeoff (eg. sio), > > wheras for others this might constitute a fatal error. The sio and cy drivers strongly prefer to use fast interrupts. The sio driver just falls back to using no interrupts if it can't attach a fast interrupt. The cy driver falls back to normal interrupt and gives up if it can't attach either type. Support for falling back is still deficient. The fallback may need to be done later when another device that requires the non-preferred type is attached. > In fact, unless I'm missing something, it looks as if there's no code > there to stop you from sharing fast interrupts. I could have sworn > there was, but the code in intr_machdep.c doesn't check. The cy This is a bug. Sharing of fast interrupts is possible but is not implemented. Drivers shouldn't need to know this. > driver also sets INTR_EXCL, which is checked for, but nexus_setup_intr > doesn't. If you share a fast interrupt and a slow interrupt, the > first-level handler becomes the mux, and so it appears that the "fast" > attribute would just go away, *without* any warning. I don't know if > there's something else that would stop it from working at all. I think implementation of sharing of fast interrupt handlers only requires a different mux that doesn't call spl*() and is attached as a fast handler. Bruce 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?Pine.BSF.4.21.0007200023590.6986-100000>