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
