>
> Hi again all, regarding this issue, something in the recently-posted
> thread 'Increasing kernel clock_tick' made me realise - the problem
> I'm getting is exactly the issue solved by the O_SYNC flag Peter
> Elliot mentions! http://www.simtec.co.uk/appnotes/AN0014/ notes this
> too -- I really was reading cached memory (as all the example code,
> including Jim Jackson's adio library do). Without the O_SYNC flag you
> get a cached representation of the IO...which gives exactly the
> symptoms I was observing!
But it doesn't explain why I've not observed your symptoms!
I had thought that using the C "volatile" sorted the problem with caching
issue. It may be alittle more complicated. Here's where my thinking is,
but I'm no expert in these areas, and would love someone to correct me.
There was a recent thread on the linux kernel email list with subject
"[patch] spinlocks: remove 'volatile'" (see
http://www.gatago.com/linux/kernel/22508695.html) which certainly opened
my eyes as to what the C "volatile" really means - essentially it simple
is an indication to the compiler not to make certain assumptions about the
state of the variable/ptr etc when optimising. It means nothing guaranteed
in hardware terms.
I suspect what is needed is some arm assembler macro to invalidate any
cached data for the relevant memory, then to read that memory
location to force a "real" read. I'm not sufficiantly up on arm
specifics to attempt this - Anybody else? It maybe that the O_SYNC flag
somehow forces this. Anyone know?
Jim
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/ts-7000/
<*> To unsubscribe from this group, send an email to:
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
|