Date: Fri, 25 Sep 1998 19:41:35 +0800 From: Peter Wemm <peter@netplex.com.au> To: Bruce Evans <bde@zeta.org.au> Cc: cgull@owl.org, gibbs@plutotech.com, shimon@simon-shapiro.org, current@FreeBSD.ORG, eivind@yes.no, mcdougall@ameritech.net, sos@FreeBSD.ORG Subject: Re: options DPT_LOST_IRQ Message-ID: <199809251141.TAA26533@spinner.netplex.com.au> In-Reply-To: Your message of "Fri, 25 Sep 1998 14:09:03 %2B1000." <199809250409.OAA32518@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Bruce Evans wrote: > >> In any case, ix86's can not process an interrupt in less than about 5 > >> i/o times (perhaps 2.5-6 usec) in the best case. If a device raises > >> and lowers its 64 times in < 64 usec, then at best the handler would see > >> about 64/2.5 separate interrupts. This is with a generous allocation of > >> 1 i/o time for device-specific interrupt handling. > > > >This isn't true for systems/software using APICs, no? > > > >A quick perusal of the code seems to show that they use memory-mapped > >I/O, less of it than a PIC, and IIRC, it's not across an > >ISA-speed bus. > > I don't know the details. I would be surprised if it were much faster, > since there are extra overheads for SMP. Even an immediately successful > spinlock normally takes at least as long as an uncached memory reference. In a nutshell: - the IO APIC is programmed for level or edge trigger and polarity. - when it gets an interrupt, it latches it until an explicit EOI. - the IO APIC sends a message across the 2-wire apic bus to the local APIC of the cpu that's been chosen to handle it. This can be round-robin or prioritized or sent to a specific CPU. - the local APIC (on the cpu silicon) receives the message and posts it internally for processing. - It's handled similarly to the "old" PIC handling, except that the PCI/ ISA interrupt interface is on a different chip and it's done via message passing over a private bus. - The message queues have a 2-deep FIFO per priority level - there is one level per 16 IDT slots.. So, slots 20-2f have a shared 2-deep fifo. This is why we tried to reassign the IDT slots so that the interrupts were spread around to make best use of the fifos. - As far as I understand it, the IO apic will resend the interrupt message if it's not acked by something. The IO apic won't unlatch until it gets an explicit message from the local apic. - the local apic has a 256-bit table of currently pending interrupts. The EOI goes for the current interrupt. There is potential for acking the wrong interrupt *if* this is done wrong. - Therefore, a short bounce of the PCI irq bus shouldn't be a problem.. - Of course, that's the theory... :-) - In reality, it would be nice if all drivers could cope with a lost interrupt. eg: if the DPT driver checked for an outstanding interrupt when a new request was being queued. That would make it self-healing (the scsi or some higher layer will cause a retry or timeout sooner or later, and a lost interrupt will be fixed on the subsequent request). There are extra potentials for problems with the SMP IRQ code, because there are at least three pieces of silicon involved (1 or more IO apic generating interrupt requests, and 2 or more local apics on the cpu's recieving them). The programming method for the APIC chips is pretty dumb.. There is an address and data register for the IO apic. > Bruce Cheers, -Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199809251141.TAA26533>