On Tue, 15 Jun 2004, Alan Stern wrote:
On Mon, 14 Jun 2004, David Brownell wrote:
Seems like the dma_alloc_coherent() API spec can't be implemented on such machines then, since it's defined to return memory(*) such that:
... a write by either the device or the processor can immediately be read by the processor or device without having to worry about caching effects.
Seems like the documentation should change to explain under what circumstances "coherent" memory will exhibit cache-incoherent behavior, and how to cope with that. (Then lots of drivers would need to change.)
OR ... maybe the bug is just that those PPC processors can't/shouldn't claim to implement that API. At which point all drivers relying on that API (including all the USB HCDs and many of the USB drivers) stop working.
- Dave
(*) DMA-API.txt uses two terms for this: "coherent" and "consistent". DMA-mapping.txt only uses "consistent".
That text strikes me as rather ambiguous. Maybe it's intended to mean that a write by either side can be read immediately by the other side, and the values read will be the ones written (i.e., the read won't get stale data from some cache). It doesn't specify what happens to the other data bytes in the same cache line which _weren't_ written -- maybe they'll be messed up.
In other words, with "coherent" or "consistent" memory (there is some technical distinction between the two terms but I don't know what it is)
<quote>
From [EMAIL PROTECTED] Mon Mar 8 23:37:22 2004
Date: Mon, 8 Mar 2004 10:58:41 -0800 From: David Mosberger <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] To: Grant Grundler <[EMAIL PROTECTED]> Cc: David Brownell <[EMAIL PROTECTED]>, [EMAIL PROTECTED], Greg KH <[EMAIL PROTECTED]>, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: [linux-usb-devel] Re: serious 2.6 bug in USB subsystem?
On Sun, 7 Mar 2004 22:18:02 -0800, Grant Grundler <[EMAIL PROTECTED]> said:
>> `Such a write-buffering mechanism is clearly a type of >> (write-)caching effect,
Grant> No - the data is still in flight and in some deterministic Grant> time frame will become visible to the CPU. Calling it a Grant> "caching effect" confuses the issues even worse.
That's why I'm so unhappy that the PCI interface used the term "consistent" memory, when it should have said "coherent". We should nail a plate on everbody's forehead saying:
consistency = coherency + ordering
Perhaps then people would start to have a clear distincition between the meaning of the two terms (or at least it would force them to think about it! ;-).
But in any case, as later experimentation confirmed, the USB bug isn't (just) an ordering issue. The order of operation described in the OHCI spec does not rely on any specific order of interrupt delivery at all, so I was wrong about that.
--david </quote>
...there does seem something bad to be going on in 2.6 with cache consistency / coherency on non-ix86 platforms. A scary lengthy thread (or threads) on ARM-kernel comes to mind. I'll have to re-read and try to understand it better though...
you don't have to worry about reading stale data from a cache, but you might still have to worry about data unintentionally being overwritten with garbage.
Clearly this is not a tremendously useful guarantee, but I guess it's better than nothing.
Maybe someone on linux-mm can clarify things for the rest of us. For anyone interested, this thread started with:
http://marc.theaimsgroup.com/?l=linux-usb-devel&m=108728413809788&w=2
Alan Stern
Thanks Guennadi --- Guennadi Liakhovetski
------------------------------------------------------- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
