That is more or less correct. And, if you want to do: fast-forward in atomic -> warm up in timing -> run in detailed, my patch will almost certainly work, since bugs have only been observed when switching back-and-forth repeatedly.
-Tony On Fri, Aug 3, 2012 at 10:26 AM, Kiyeon Lee <[email protected]> wrote: > Hi, Tony and Ali. > Thanks for your quick response. I did not have time to try your patches > yet, but I'm glad to know that there are patches that may help solving my > problem. > > Please let me I ask a question to clarify the "draining" problem. > The drain functionality is used to complete all outstanding transactions > before switching between the simulation modes. Then, if I used > AtomicSimpleCPU before switching to the other timing-aware CPU models, I > should not have any problem with draining because there are no outstanding > operations. > For instance, if I switch from AtomicSimpleCPU to TimingSimpleCPU, or from > AtomicSimpleCPU to O3CPU, there is no problem because there is nothing to > drain. > However, if I switch from TimingSimpleCPU or O3CPU, I may have problem > with draining. > Is my understanding correct? > > Thanks in advance!! > > Kiyeon > > > > > On Wed, Aug 1, 2012 at 2:24 PM, Anthony Gutierrez <[email protected]>wrote: > >> I submitted a more up-to-date version of patch #1221 with a few more >> fixes to some known problems and some DPRINTF statements specifically for >> draining that you may find useful. I have some other things that I have >> tried, but don't know think I should post them yet because I don't know if >> they actually do anything useful. >> >> To me it seems like you're exiting simulate() inside of the drain() >> function prematurely, i.e., because the max tick is reach and not because >> all objects processed their drain event. Look at the new debug output from >> the updated patch #1221 to see which objects didn't drain. >> >> Also, I recommend using doDrain() as opposed to drain(). >> >> Thanks, >> Tony >> >> On Wed, Aug 1, 2012 at 10:45 AM, Kiyeon Lee <[email protected]> wrote: >> >>> Hi. >>> >>> I am trying to run a full-system multicore simulation using the ARM >>> "VExpress_EMM" platform modeled in gem5. I am using the latest source >>> codes from the gem5 repository. >>> >>> I configured the system to have 4 processor cores and use the classic >>> memory subsystem model, and created a checkpoint using a functional >>> simulation assuming 4 cores with no caches. >>> The checkpoint was created after the system was booted-up using >>> functional simulation, and after I executed 4 different SPEC 2006 >>> benchmarks. >>> To exploit the checkpoint, I restored the checkpoint and then warmed-up >>> the system using a TimingSimpleCPU. >>> However, after the specified warm-up period, when I switch to O3CPU from >>> TimingSimpleCPU, I get the following error. >>> >>> gem5.opt: build/ARM/python/swig/pyevent.cc:84: void >>> cleanupCountedDrain(Event *): Assertion 'event->getCount()==0' failed >>> >>> Is there anyone who has faced the same issue as I described above? If >>> so, how did you resolve the issue? >>> Is multicore simulation stable in gem5 ARM architecture? >>> >>> Thanks. >>> >>> Best Regards, >>> Kiyeon >>> >>> >>> >>> _______________________________________________ >>> gem5-users mailing list >>> [email protected] >>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >>> >> >> >> _______________________________________________ >> gem5-users mailing list >> [email protected] >> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >> > > > _______________________________________________ > gem5-users mailing list > [email protected] > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
