Date: Mon, 11 Apr 2005 01:08:51 -0600 From: Scott Long <scottl@samsco.org> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: freebsd-current@freebsd.org Subject: Re: Potential source of interrupt aliasing Message-ID: <425A2283.7040405@samsco.org> In-Reply-To: <200504110658.j3B6w2nb048552@apollo.backplane.com> References: <20050406233405.O47071@carver.gumbysoft.com> <200504081656.51917.jhb@FreeBSD.org> <20050410152946.W82708@carver.gumbysoft.com> <20050410172818.D82708@carver.gumbysoft.com> <200504110231.j3B2VOYr047361@apollo.backplane.com> <425A10DD.70500@samsco.org> <200504110658.j3B6w2nb048552@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Matthew Dillon wrote: > Hmm. I can think of two solutions that avoid masking: > > * Change the trigger mode from level to edge as a means of masking the > interrupt, then change it back to level triggered to unmask. This > would be done in the IO APIC. > > * Change the delivery mode to low-priority for the interrupt that occured > and use the priority field to mask the interrupt to the cpu. This > would be done in the IO APIC with the LAPIC's TPR set appropriately. > > These are off-the-cuff ideas. I don't know how easy or hard it would be > to implement (yet). But, certainly, changing the trigger mode can't be > any more complicated then messing around with the mask. > > -Matt This is a place where two-level interrupt handling like in Mac OSX starts looking attractive. You have the driver quench the source right away in what is basically a fast interrupt handler, then you have an ithread come along later and process the data. I somewhat approximate this with the AAC driver, though I use a taskqueue instead of an ithread. There are definite trade-offs here; sometimes the only way to quench the hardware is to dequeue a status byte that is needed for later data processing. Queueing up this data byte to an ithread, and accounting that there might be more interrupts before the ithread runs, is ugly. Btw, AAC doesn't exhibit aliasing problems in the chipsets that I mentioned precisely because we don't mask the IOAPIC for fast handlers. Unfortunetaly, moving the entire OS to this scheme is quite labor-intensive. It would make just as much sense to implement MSI infrastructre and convert a number of drivers to that. And again, Linux seems immune to this problem, so it's very intriguing to find out why. Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?425A2283.7040405>