On Tue, 2007-11-20 at 09:29 +0100, Thomas Bogendoerfer wrote: > On Tue, Nov 20, 2007 at 06:51:14AM +1100, Benjamin Herrenschmidt wrote: > > > > On Mon, 2007-11-19 at 00:38 -0800, David Miller wrote: > > > From: Benjamin Herrenschmidt <[EMAIL PROTECTED]> > > > Date: Mon, 19 Nov 2007 16:35:23 +1100 > > > > > > > I'm not sure what is the best way to fix that. Internally, I've done > > > > some test whacking some ____cacheline_aligned in the scsi_cmnd data > > > > structure to verify I no longer get random SLAB corruption when using my > > > > USB but that significantly bloats the size of the structure on archs > > > > such as ppc64 that don't need it and have a large cache line size. > > > > > > > > Unfortunately, I don't think there's any existing Kconfig symbol or arch > > > > provided #define to tell us that we are on a non-coherent arch afaik > > > > that could be used to make that conditional. > > > > > > > > Another option would be to kmalloc the buffer (wasn't it the case before > > > > btw ?) but I suppose some people will scream at the idea due to how the > > > > command pools are done... > > > > > > You could make a ____dma_cacheline_aligned and use that. > > > It seems pretty reasonable. > > > > I was thinking about that. What archs would need it ? arm, mips, what > > else ? > > older parisc
Actually, we already established on IRC that the lasi700 driver doesn't need this, principally because the parisc architecture doesn't do an invalidate for DMA_FROM_DEVICE but a flush and invalidate (architecturally, if you read our manuals, even pdc is entitled to write back dirty lines, so it's not clear there's actually an invalidate instruction we can use). This is also one possible temporary fix for the other architectures if we can't get a different method to work nicely. James James - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
