Am Montag, 27. November 2006 04:22 schrieb David Brownell:
> On Sunday 26 November 2006 6:46 pm, Alan Stern wrote:
> > On Sun, 26 Nov 2006, David Brownell wrote:
> >
> > > On Thursday 23 November 2006 6:19 am, Oliver Neukum wrote:
> > > > Hi,
> > > >
> > > > gl620a uses a buffer within a struct. This can corrupt memory on
machines
> > > > that are not cache coherent.
> > >
> > > How could it possibly corrupt memory?
> >
> > It would be more accurate to say that it could corrupt the contents
of the
> > buffer during an input operation. I don't think it matters as far as
> > output is concerned...
>
> The question still remains: how could this corruption happen?
By reading irq_urb before the cache coherency operation. In this case
the buffer contents read latter can be corrupted as far as they share
a cache line.
Regards
Oliver
This cache coherency problem is interesting and hard to describe. I have
seen it on both MIPS and ARM processors. Intel stuff "snoops" the bus so
that the CPU cache knows what other memory accesses are going on (ie other
processors or DMA). This snooping helps programmers, but obscures the
underlying problem and with the expected doubling of processors every 2
years will become a problem on X86 processors in the future.
There are 4 possible errors with non-coherent caches where the CPU and
"another" memory accessor such as DMA can change memory.
CPU DMA
0 0 - nobody accessing it, no harm, no foul
0 1 - dma changes, cpu does not care
1 0 - cpu changes , dma does not care
1 1 - both cpu and dma access memory - possible problem
In simultaneous access there are 4 possible problems
CPU DMA
R R - both have read memory their view are the same
R W - CPU reads, later DMA writes, CPU cache is incorrect
W R - DMA will send either obsolete data or new depending on if CPU flushed.
W W - both write, whichever writes/flushes last wins, his data goes into
memory.
I have seen a problem where the cpu was reading a cache line that contained
both the status of the operation and the hid (1 byte data) buffer. Since the
CPU was polling the status location, the cache line was fresh, the DMA data
is never seen. This is especially bad when DMAing to a location on the
stack. The stack is very likely to be freshly in cache, so a DMA into the
underlying memory will disappear.
In Googling for a better description I found:
From: Eugene Surovegin
Consider the following scenario, you allocated page from kernel page
allocator. Some parts of that page are in L1 cache and are dirty
(e.g. because they were recently used), I'm assuming cache is
write-back. You start DMA transfer and go on with some other tasks.
For some reason, those dirty lines are forced out of cache, e.g.
because L1 needs cache lines for some other data. During this write
back you overwrite already DMAed data and end up with memory
corruption.
Regards ~Steve
_________________________________________________________________
View Athletes Collections with Live Search
http://sportmaps.live.com/index.html?source=hmemailtaglinenov06&FORM=MGAC01
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
