I'm also seeing a new one when I disable prefetchers and run stream again: build/ALPHA_FS/mem/cache/cache_impl.hh:1335: Packet* Cache<TagStore>::getTimingPacket() [with TagStore = LRU]: Assertion `tags->findBlock(mshr->addr) == __null' failed.
command line: m5/configs/example/dramsimfs.py -F 10000000000 --mp "physicaladdressmappingpolicy sdramhiperf commandorderingalgorithm bankroundrobin rowBufferPolicy closepage" -b stream I wonder if this could be the memory simulator handling the packet requests incorrectly, i.e. returning a packet that didn't need a response or something like that. The prefetcher was disabled, caches were set as follows: test_sys.l2 = L2Cache(size = '512kB', assoc=16, latency="6ns") test_sys.cpu[i].addPrivateSplitL1Caches(L1Cache(size = '64kB'),L1Cache(size = '64kB')) If you aren't able to replicate these, then we should compare setups and fix whatever's going on with my system. Or if you need any other info on how I'm running simulations, please let me know. Joe Steve Reinhardt wrote: > Thanks... I think you had mentioned that assertion failure before but > it's not one I've been able to reproduce so I forgot about it. Sorry > about that. I'll try again to see if I can reproduce it. > > Steve > > On Tue, Sep 29, 2009 at 12:33 AM, Joe Gross <[email protected]> wrote: > >> Steve, >> >> Thanks for looking into this. I'm able to get the stream benchmark to >> run to completion now. >> >> I'm not sure if this is the problem you're talking about (so sorry in >> advance if this is a repeat), but I'm still having trouble running bzip2 >> and getting the assertion error: >> build/ALPHA_FS/mem/cache/mshr.hh:228: MSHR::Target* MSHR::getTarget() >> const: Assertion `hasTargets()' failed. >> >> This turns into a segfault on m5.fast. >> >> I pulled your changes a few days ago and have been testing them out >> after updating a few of my files (changes pushed to my head rev). I >> tried running again with the prefetcher moved to the L1 cache and even >> removed all prefetchers from the system and still get this assertion, so >> I think this isn't related to the prefetcher, but I could be wrong. I >> even removed the old workaround of increasing the tgts_per_mshr and it >> remains. >> >> I use these flags when running to get the assertion error (config files >> no longer necessary): >> m5/configs/example/dramsimfs.py -b bzip2 -F 10000000000 --mp >> "physicaladdressmappingpolicy sdramhiperf commandorderingalgorithm >> bankroundrobin rowBufferPolicy closepage" >> >> Joe >> >> Steve Reinhardt wrote: >> >>> Joe, >>> >>> I think with the changes I pushed recently both the CPU stalling and >>> the assertion failure should be taken care of. Note that if you pull >>> from the head you'll have to make some minor changes in your python >>> scripts because of some code reorganization that Nate did. >>> >>> Unfortunately I've run into another bug that's more complicated to >>> fix: because our cache hierarchy does not enforce inclusion, it's >>> possible for the L2 prefetcher to prefetch a block that's already >>> modified in the L1 and end up prefetching a stale copy out of main >>> memory. In at least one situation (where the L1 writes its modified >>> copy back to the L2 in the interval between where the L2's prefetch is >>> issued and the prefetch response returns), the stale copy can >>> overwrite the modified copy and data is lost. I think the best way to >>> address this is to have L2 prefetches probe the L1s, but there's no >>> clean mechanism for that right now, so it's not a trivial fix. In the >>> meantime, having the prefetcher be associated with the L1 dcache and >>> not the L2 should be sufficient to avoid this problem. >>> >>> Please let us know if you run into anything else... >>> >>> Steve >>> _______________________________________________ >>> m5-users mailing list >>> [email protected] >>> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users >>> >>> >> _______________________________________________ >> m5-users mailing list >> [email protected] >> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users >> >> > _______________________________________________ > m5-users mailing list > [email protected] > http://m5sim.org/cgi-bin/mailman/listinfo/m5-users > _______________________________________________ m5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
