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
