Hey Andreas, Do you have any idea about this problem:
http://www.mail-archive.com/[email protected]/msg06550.html Thanks, Tony On Mon, Jan 28, 2013 at 4:31 AM, Andreas Sandberg <[email protected]>wrote: > On 01/25/2013 10:00 PM, Amin Farmahini wrote: > >> I have developed a model that frequently switches between cpus. To be more >> specific, I switch between O3 and a cpu model of mine. After new changes >> to >> O3 draining >> (http://reviews.gem5.org/r/**1568/<http://reviews.gem5.org/r/1568/>), >> I have encountered two >> assertion failures. >> >> 1. assert(predHist[i].empty()); in BPredUnit<Impl>::**drainSanityCheck() >> (src >> /cpu/o3/bpred_unit_ipml.hh) >> Prior to new patch, we squashed the history table before switching, but as >> far as I understand, we don't do so any more in the new patch. This >> assertion failure happens, for example, when you switch from atomic to o3 >> and then from o3 to atomic. >> > > This is a bug in the draining code. Just comment out the code in > drainSanityCheck and you should be fine. I'm a bit surprised that we > haven't seen this in the regressions, it seems to be that this assertion > would trigger on every single O3 CPU drain/resume. > > > 2. assert(!cpu->switchedOut()); in DefaultFetch<Impl>:: >> processCacheCompletion (src/cpu/o3/fetch_impl.hh) >> Obviously this happens when fetch stage in O3 receives a packet from cache >> (possibly after an Icache miss) while the o3 is switched out. Again, >> previously, we used to detect such a situation and activate the fetch only >> if no drain is pending. >> > > I don't think this should by possible any more, it's most likely a bug > somewhere else if the assertion triggers. BaseCPU::takeOverFrom disconnects > both the icache and dcache when switching between CPUs, so the CPU should > never be switched out and connected to a cache at the same time. Besides, > the new O3 draining should wait for /all/ outstanding requests to complete > or be squashed. As far as I'm concerned, the the draining code is buggy if > there are still pending ifetches in a drained system. > > > > I have found a solution to work around these assertion failures, and I am >> not sure if this only happens to me because of the specific way I use the >> O3 draining or not. I just wanted to mention these assertion failures >> could >> be possible bugs. >> >> > The first assertion is almost definitely a bug. I suspect the second one > could be due to a bug in your configuration scripts or in your CPU model. > Are you using any of the example scripts? Or have you rolled your own? If > so, could you send us/me a copy so I can have a look? > > //Andreas > > > ______________________________**_________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/**listinfo/gem5-dev<http://m5sim.org/mailman/listinfo/gem5-dev> > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
