http://reviews.m5sim.org/r/1294/diff/#index_header
Should fix part of the issue. Lena was working on a better solution that didn't required a "hack," but I haven't seen that yet. As for the other part of the fix.. there is another hack I committed to fix an issue, but apparently there must be another place that needs fixing. Again, hopefully Lena's change fixes this properly, but take a look at: http://repo.m5sim.org/gem5/rev/08cc303b718b And you can apply the same fix to the place where you're hitting an issue. Just check if the current block is the tempBlk and if it is invalidate it first. Ali On Jul 28, 2012, at 2:28 PM, Uri Wiener wrote: > Hello list members, > > I'm running PARSEC benchmarks on a system with 4 timing CPUs in a 2-cluster > formation with an L2 per cluster, and private I&D L1 caches per CPU. > Some of my simulations break because of the following assertion: > > lru.cc: > > void LRU::invalidateBlk(BlkType *blk) > { > ... > assert(blk->srcMasterId < cache->system->maxMasters()); > > One of the CPUs issues a write to its dcache, causing a miss, resulting in > a read-exclusive request. > While handling the response, the L2 cache's handleResponse calls > handleFill, which calls allocateBlock (hence a replacement is needed), yet > allocation fails, causing the cache to use tempBlock to complete the > current request. > handleResponse eventually calls satisfyCpuSideRequest with the tempBlock. > since this is a 2-level cache hierarchy, invalidateBlk is called. > > And here is the problem: > The block used is the tempBlock, which was assigned with a default-value > srcMasterId, causing the assertion to fail. > From a hesitant guess, I think LRU::invalidateBlk isn't intended to be > called with tempBlock. > Even if the tempBlock would have a valid srcMasterId, moveToTail() would > fail as tempBlock isn't a block from any set, and the following assertion > would fail: > > cacheset.cc: > > void CacheSet::moveToTail(CacheBlk *blk) > { > ... > assert(i >= 0); > > > The general scenarios I'm trying includes slowing down snoop responses. > This might cause the L2 to fill its mshr, starting this whole mess. > > Does this seem like a plausible scenario? > > Thanks, > > Uri > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
