Re: Linux 2.6.30-rc8 [also: VIA Support]

[Michael S. Zick]

On Thu June 4 2009, Robert Hancock wrote:
> Michael S. Zick wrote:
> > On Thu June 4 2009, Andi Kleen wrote:
> >> Harald Welte <HaraldWelte@xxxxxxxxxxx> writes:
> >>> why would it matter on UP? as indicated, I'm not the expert here, but I thought
> >>> memory ordering issues only arise in SMP systems [or possibly with regard to
> >>> DMA, but as we already explored much earlier in this thread, drivers that access
> >>> DMA buffers whil the hardware owns them are buggy and need to be fixed]
> >> Sorry we didn't establish that. Accessing data structures that are
> >> also accessed by DMA hardware is pretty common in fact and memory
> >> ordering issues also come up regularly (e.g. all the infamous PCI
> >> posting bugs)
> >>
> >> What we established is that the drivers don't use LOCK for it
> >> (or at least we think that's very unlikely)
> >>
> > 
> > It was a real headache in the pa-risc port - -
> > Even went so far as to build some experimental kernels where all
> > the spin-lock structures where in a separate loader section.
> > 
> > That was to avoid in-direct interference - I.E: Both DMA and
> > the processor handling the locking **both** invalidating the
> > same cache line at the same time (only one can win).
> > 
> > Things might get that deep with this processor/chip-set combination;
> > but pa-risc has some very unusual hardware in some older models.
> 
> That sort of thing should be architecturally impossible on x86. In order 
> for something to invalidate the cache line, it first has to own it 
> (except maybe for some unusual cases like Memory Write and Invalidate 
> where the writer promises to overwrite the entire cache line).
> 
> 

VIA has not publicly published sufficient technical information to presume
that the cache coherency control protocols are the same as Intel's.

These are cpu/chipset pairs - Think System On 2 Chips. SoS2C.

Mike
Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/