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>