[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