Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 3 Nov 1996 14:28:30 -0700 (MST)
From:      Terry Lambert <terry@lambert.org>
To:        smp@csn.net (Steve Passe)
Cc:        terry@lambert.org, dg@Root.COM, hackers@freefall.freebsd.org, smp@freefall.freebsd.org, bde@zeta.org.au
Subject:   Re: ed0 timeouts
Message-ID:  <199611032128.OAA03249@phaeton.artisoft.com>
In-Reply-To: <199611032115.OAA29180@clem.systemsix.com> from "Steve Passe" at Nov 3, 96 02:15:59 pm

next in thread | previous in thread | raw e-mail | index | archive | help
> > > It is strongly recommended that first 82489 (ie APIC) should be unmasked
> > > and then the device interrupt should be enabled.  By this sequence software
> > > can ensure that always an edge will occur at the APIC input only after
> > > the interrupt is unmasked.
> > 
> > Or: "Don't ack the thing until fater it's unmasked".
> 
> Huh?  forgive me, not enough sleep...  Is this sarcasm or a suggestion that
> is going over my head?

I think if you don't ack it, it will not allow another one in.

This sort of implies you don't mask the way we currently mask, and
it also implies a big latency (which I don't like at all) in taking
the interrupt.  Then you "manually" ack.

I don't know what NT does, but SVR4 ES/MP used a two level interrupt
handling mechanism, where the interrupt and all state from the hardware
was saved off and queued for processing later.  This let them weenie
out on acking, but didn't add full processing overhead to the thing.
Ie: if I get an int from a card that needs something read off it, it's
read off immediately into a driver buffer, then acked, then queued for
processing.

Have you looked at the Windows 95 interrupt processing code?  It's
very similar.  In some cases (bus master DMA hardware), there's a
big concurrency win allowing interrupts from devices before the
data from the previous interrupt is actually processed.  I suspect
the 95 and NT processing is similar (I haven't dived into WinICE on
NT yet -- probably within the next month, though).

Win95 can't allocate memeory at interrupt time, so the buffer allocation
has to come from a free list, or from the ack routine (which is technically
not run at interrupt level.

I think there would be a big code impact on BSD to adopt this type
of processing, but it might be worth it to work around your problem
in the long run.  From what David said, it looks like this is a
generic ISA problem; I'd be surprised if it hasn't bit people without
APIC's.

I think the patch Bruce posted is a move in this direction (or at least
that's what it looked like to me).


					Regards,
					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611032128.OAA03249>