[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MiNT] Fix wrong size of outgoing packets in the FEC driver
On 04/09/2014 21:14, markus@mubf.de a wrote:
I have looked before into the TAS() macro, but didn't see anything
suspicuous - frankly, I didn't know tas is behaving bad on the Firebee.
The Coldfire manual doesn't say anything special about it (the text is
the same as for m68k processors), do you know more?
Now I remember! That's a data cache issue.
If I understand correctly:
The special read-modify-write operation occurs at the bus level, to deal
with multiple bus master devices. That's exactly the job of TAS.
But that operation does not care about the data cache!
If you set a variable to 0 to release a lock, its value will be 0 in the
data cache, but will stay to the old value in the actual memory (at
least when the data cache is in copy-back mode).
Then if you use TAS to read the variable, you will read the old stale
value instead of your 0. This means that the lock may appear to be
locked from another task, while it is actually our old lock.
Then the OS does other things (did you remember my report about
improvements with sustained screen activity?). Finally, the data cache
line is flushed, the 0 is pushed to memory and the algorithm unlocks.
This is exactly what I experienced with the NFS client on the FireBee.
On the other side, the BSET instruction only works in the the data
cache, it doesn't care about the actual memory.
As a conclusion, the TAS instruction can't be used in memory areas
configured with data cache in copy-back mode. However, that should work
with write-through or cache-inhibited areas.
It would be interesting to know if the NFS client also had trouble with
other processors (68060?) in copy-back mode...
--
Vincent Rivière