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

Michael S. Zick
2009-06-05T00:52:47Z

On Thu June 4 2009, Robert Hancock wrote:
> Michael S. Zick wrote:
> > On Thu June 4 2009, Andi Kleen wrote:
> >> Harald Welte <HaraldWelte@viatech.com> 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