Re: SCSI breakage on non-cache coherent architectures

[James Bottomley <James.Bottomley@HansenPartnership.com>]

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 <benh@kernel.crashing.org>
> > > 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-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/