Hi Andreas, Where is the patch? It doesn't seem to be attached.
Thanks, Tony On Thu, Feb 7, 2013 at 11:24 AM, Andreas Sandberg <[email protected]>wrote: > Hi Tony, > > There was a small mistake, well actually, a pretty large one, in the patch > I sent you. The patch actually breaks draining completely... :( > > I've attached the new version of the patch. Sorry for the confusion. > > I tried to reproduce the bug using the current tip/master with the patch > applied and the simulation gets stuck around tick 6901819000 instead (I > used the same command line as you did). It seems like it's something to do > with L2 draining, but I haven't figured out the details yet. > > //Andreas > > > On 02/05/2013 03:50 PM, Anthony Gutierrez wrote: > >> Hi Andreas, >> >> The changeset I was using when I ran into this problem was this one: >> http://repo.gem5.org/gem5/rev/**f9e76b1eb79a<http://repo.gem5.org/gem5/rev/f9e76b1eb79a> >> . >> >> I tried with the patch; it no longer asserts, but now the simulation seems >> to hang. The kernel and disk image I am using are from: >> http://gem5.org/bbench-gem5. The gingerbread image with bbench and the >> kernel are there. >> >> With the latest repo (unmodified) repeat switching also causes the >> simulation to hang and never hits that assert. >> >> Thanks, >> Tony >> >> On Mon, Feb 4, 2013 at 3:02 PM, Andreas Sandberg <[email protected] >> >wrote: >> >> Hi Tony, >>> >>> I had a quick look and was unable to reproduce it myself. Could you >>> check if it is still a problem and send me your kernel binary in that >>> case? >>> >>> I suspect that the problem is that there are cases when we don't reset >>> the memReq[tid] pointer when a request is has been squashed. Could you >>> test to see if the patch I've attached solves the issue? The fix is also >>> included in my gem5 fixes branch [1]. >>> >>> //Andreas >>> >>> [1] https://github.com/andysan/**gem5 <https://github.com/andysan/gem5> >>> >>> On Mon, 2013-01-28 at 11:08 -0500, Anthony Gutierrez wrote: >>> >>>> Hey Andreas, >>>> >>>> Do you have any idea about this problem: >>>> >>>> http://www.mail-archive.com/**[email protected]/msg06550.**html<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/> >>>>>> < >>>>>> >>>>> 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> >>>>> < >>>>> >>>> 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<http://m5sim.org/mailman/listinfo/gem5-dev> >>>> >>> >>> >>> ______________________________**_________________ >>> 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<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
