OK, this is about the fourth time I've composed a response, because every time I start I think of some more things to look at and then what I see makes me change my mind about where I think the problem is.
My current theory revolves around the optimization described in the comment here: http://repo.gem5.org/gem5/file/bfc59fbde824/src/mem/cache/cache_impl.hh#l211 This hasn't caused a problem before, but I see now that if the block is writable but not dirty, the state is not modified, which isn't right... I'm guessing that under normal operation there's no way the block can be writable but not dirty, so we never enter the "else if (blk->isWritable()" part without also entering the "if (blk->isDirty())" section. Perhaps by fetching the block with a prefetch (and not having the shared line asserted on the response) we end up with a writable but not dirty copy, which then takes us down this untested path when satisfyCpuSideRequest() is called for the miss. I *think* the fix is to just get rid of the "if (blk->isDirty())" condition and make the code inside that if be unconditional; certainly something has to be done if the block is writable but not dirty, and my initial thought was that there should be an else clause after that if, but after a bit more thought I think the actions are the same regardless of whether the block is dirty. Does that make sense? Steve _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
