From owner-freebsd-smp Mon Jul 17 10: 5:19 2000 Delivered-To: freebsd-smp@freebsd.org Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by hub.freebsd.org (Postfix) with ESMTP id A547837BBAD; Mon, 17 Jul 2000 10:05:05 -0700 (PDT) (envelope-from jre@iprg.nokia.com) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA21292; Mon, 17 Jul 2000 10:05:04 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id KAA17809; Mon, 17 Jul 2000 10:05:03 -0700 X-Virus-Scanned: Mon, 17 Jul 2000 10:05:03 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from radio.iprg.nokia.com (205.226.1.150, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpdH6iIWK; Mon, 17 Jul 2000 10:04:58 PDT Message-ID: <39733CBB.7147BA74@iprg.nokia.com> Date: Mon, 17 Jul 2000 10:04:59 -0700 From: Joe Eykholt Organization: Nokia IPRG X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Steve Passe Cc: Greg Lehey , arch@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: Tidying up the interrupt registration process References: <200007171553.JAA24715@Ilsa.StevesCafe.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Steve's correct about the fast interrupt being needed to prevent overflow of the serial FIFOs. So, FAST interrupts haven't been blocked by spl (even splhigh) and the lower half of the driver has to disable interrupts in order to blcok the FAST interrupt. Just one more thing to consider: its pretty nice when using a serial console to be able to break into the debugger even when at splhigh(), and the FAST_INTR setup allows this. If serial interrupts were threads, then this probably wouldn't be possible. Solaris 2.5 (and probably the more recent versions also) uses the equivalent of fast interrupts for serial also. Joe Steve Passe wrote: > > Hi, > > > I think I now understand how drivers register interrupts with newbus, > > and it seems that some tidying up is in order. > > ... > > About fast interrupts, which currently seem to be used only by the sio > > driver: they perform their entire work before reenabling interrupts, > > and it's possible that we can keep them like that, though I haven't > > looked at the code yet. Does anybody know any reason why we should > > convert them to threaded interrupts? > > Its been quite awhile since I looked at this code, so forgive any inaccuracies > on my part... I believe the sio FAST_INTR gets away with "they perform their > entire work before reenabling interrupts" because it defers much of the work > to the tty soft INTR level. In the ISR itself, it drains the hardware ASAP, > then lets the soft INTR process the queues, etc. This method is used to > prevent overflowing the sio fifos, which would otherwise occur if the INT were > defered till spl() said it could proceed. If the new kernel model allows > INTR threads to preempt, I would favor eliminating this sio 'special case', > and use high priority for the sio ISR to get the same effect. I am a great > fan of ISRs that look something like: > > sio_intr( struct threadStuff * s ) > { > ssignal( &(s->intrSem) ); > } > > -- > Steve Passe | powered by > smp@csn.net | Symmetric MultiProcessor FreeBSD > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-smp" in the body of the message -- Joe Eykholt jre@iprg.nokia.com +1 650 625 2041 Nokia Internet Communications http://www.iprg.nokia.com 313 Fairchild Drive, Mountain View, CA 94043 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message