Date: Mon, 11 Apr 2005 11:45:47 -0400 (EDT) From: Andrew Gallatin <gallatin@cs.duke.edu> To: Scott Long <scottl@samsco.org> Cc: freebsd-current@freebsd.org Subject: Re: Potential source of interrupt aliasing Message-ID: <16986.39851.597421.478406@grasshopper.cs.duke.edu> In-Reply-To: <425A10DD.70500@samsco.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
Scott Long writes: > > See also: sbus(4), msi(4). > > MSI is something that I'd like to work on, but simply had the time. > It's not a panacea since it will only work for MSI-enabled PCI devices, > but many peripherals found on these Intel systems fall into that > category. Bear in mind that MSI is another can of worms. I spent some time last month getting MSI interrupts working for our linux driver. I had the misfortune to start with a system (ServerWorks GC-SL based) which did not even support MSIs, but where linux let my driver enable MSI operation and allocate MSI interrupts. Any DMA to the address given by the linux MSI code resulted in a PCI master abort. That was not fun.. If/when we do MSI support, I really hope we do a better job of determining if MSIs actually work before enabling them ;) Drew
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?16986.39851.597421.478406>