Pete Popov wrote: > > Ralf Baechle wrote: > > > > On Wed, Jan 24, 2001 at 12:10:32PM -0800, Jun Sun wrote: > > > > > It is really surprising to know this. It sounds like a CPU bug to me. Can > > > some MIPS "gods" clarify if such a behaviour is a bug or allowed? > > > > > > BTW, the CPU in EV96100 is QED RM7000, I believe. > > > > If you want to be strictly correct you have to execute the code that > > disables caching of KSEG0 in uncached space like KSEG1, then flush the > > caches before you can resume execution in KSEG0. Otherwise you might > > end up with dirty d-caches which when flushed will overwrite more > > uptodate data in memory. The window is very small but yet exists if > > things are just right. > > The EV96100 running Galileo's pmon exhibits exactly this symptom. Pmon > apparently sets up kseg0 to cache coherency 3; but eventhough the > kernel also sets it to 3, if I don't flush the caches first I end up > with overwritten data. A different version of pmon that I have sets > kseg0 to 1 (writethrough). Changing that to 3 isn't a problem -- or at > least it doesn't seem to cause any problems. > I don't think it is the same problem. Here is the simplified view of the process, if I understand Pete correctly: 1. pmon sets kseg0 to 3 (cache enabled) 2. kernel starts in KSEG0 3. kernel sets kseg0 to 3 again (essentially keeps the same config value) 4. kernel flushes cache ===> Q: data corruption or not? I think the data should be consistent. Otherwise it looks like a CPU bug to me. What ralf described is something like the following: 1. pmon sets kseg0 to 3 (KSEG0 cache enabled) 2. kernel starts in KSEG0 3. kernel sets kseg0 to 2 (disable kseg0 cache) 4. kernel flushes cache ===> Q: data corruption or not? YES, data can be corrupted! Jun
