Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 17 Jul 2000 10:04:59 -0700
From:      Joe Eykholt <jre@iprg.nokia.com>
To:        Steve Passe <smp@csn.net>
Cc:        Greg Lehey <grog@lemis.com>, arch@FreeBSD.ORG, smp@FreeBSD.ORG
Subject:   Re: Tidying up the interrupt registration process
Message-ID:  <39733CBB.7147BA74@iprg.nokia.com>
References:  <200007171553.JAA24715@Ilsa.StevesCafe.com>

next in thread | previous in thread | raw e-mail | index | archive | help

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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?39733CBB.7147BA74>