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
