Hi Andreas, Thanks for taking the time for fixes. I have already applied the same patch to fix the first problem. So this should fix the problem.
To regenerate the second problem, I have to send you a lot of my patches because I have highly modified gem5. Since others have not reported such a problem, I'd guess this is caused by my patches. So, please disregard the second problem. Thanks, Amin On Mon, Feb 4, 2013 at 2:06 PM, Andreas Sandberg <[email protected]>wrote: > Amin, > > I've attached a patch that solves the first of your problems. It is also > available in my fixes [1] branch. I haven't been able to figure out > what's causing the second one. > > Could you send me the command line you use when you trigger the problem? > Do you have a minimal (small) test code reproduces the bug? > > I'll post the patches for review once we have sorted out both of the > issues. > > //Andreas > > [1] https://github.com/andysan/gem5/tree/fixes > > On Mon, 2013-01-28 at 10:19 -0600, Amin Farmahini wrote: > > Hi Andreas, > > > > Thanks for the response. I don't use a script for switching cpus. I have > > added an m5 magic instructions to drain the pipeline and switch cpus. So, > > as you know mentioned, it is highly likely that the second bug could be > due > > to my magic instruction. > > > > Thanks, > > Amin > > > > > > On Mon, Jan 28, 2013 at 10:08 AM, Anthony Gutierrez <[email protected] > >wrote: > > > > > 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 > > > > > _______________________________________________ > > 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 > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
