Messages in this thread | | | Date | Fri, 23 Mar 2007 15:22:07 -0700 | From | Greg KH <> | Subject | Re: [PATCH 2.6.20.3] Flush writes to MSI-X table |
| |
On Fri, Mar 23, 2007 at 02:50:45PM -0700, Kok, Auke wrote: > Greg KH wrote: > >On Thu, Mar 22, 2007 at 02:08:19PM -0700, Mitch Williams wrote: > >>Because both MSI-X interrupt messages and MSI-X table writes are posted, > >>it's possible for them to cross while in-flight. This results in > >>interrupts being received long after the kernel thinks they're disabled, > >>and in interrupts being sent to stale vectors after rebalancing. > >> > >>This patch performs a read flush after writes to the MSI-X table for > >>enable/disable and rebalancing operations. Because this is an expensive > >>operation, we do not perform the read flush after mask/unmask > >>operations. Hardware which supports MSI-X typically also supports some > >>sort of interrupt moderation, so a read-flush is not necessary for > >>mask/unmask operations. > >> > >>This patch has been validated with (unreleased) network hardware which > >>uses MSI-X. > > > >Is this needed for any hardware that is public today? > > yes. Every msi-x capable piece of hardware in the field will crash if it > does any form of interrupt balancing. (okay that is not that much stuff out > there... I know, but the patch is not that big at all - all it does is > subtly add a few read flushes to make sure that critical changes in the > msix vector tables are pushed out at the proper time). > > >Also, it seems a bit too big of a patch for -stable right now, > >especially as the mainline patch will not make it into 2.6.22 at the > >earliest. > > I think Mitch was way too sensitive when he worded his e-mail. We should > really be trying to get this fix into 2.6.21 at least. > > Mitch, can you re-post this and include Eric Biederman, linux-pci, our > intel platform guys and perhaps Linus and Andrew? > > A lot of vendors (not just us) will be pushing msi-x capable hardware out, > and this fix is absolutely needed. Getting it in soon is really preferred. > Not to mention that Mitch has spent well over 8 weeks I think making sure > that this is indeed the issue and the proper fix...
Well, I'm sure you can agree that it is _very_ late in the 2.6.21 release cycle to expect to get this in for that kernel. How about waiting for 2.6.22 and if it's a big deal, getting it into the 2.6.21-stable tree if needed.
So far I have not seen any bug reports that this patch would fix, have you?
thanks,
greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |