Also if you're curious, to answer your question why this is happening: when drain() is called it goes back into simulate() without specifying the number of ticks. So, it defaults to MaxTick, meaning it will try to simulate for curTick() + MaxTick, but obviously MaxTick is the highest possible value so anything added to it will cause a roll over. Now that Tick is unsigned the check for < 0 doesn't register and thus the overflow is not detected. The patch I posted corrects this.
-Tony On Mon, Aug 27, 2012 at 11:49 AM, Anthony Gutierrez <[email protected]>wrote: > Have you tried with this patch? I was getting similar problems with > drain(), although not with checkpointing. It works for me with this patch. > > http://reviews.gem5.org/r/1367/ > > Thanks, > Tony > > > On Mon, Aug 27, 2012 at 11:35 AM, Jason Power <[email protected]> wrote: > >> Hi all, >> >> Since revision 9158:d152d34a4adf (Clock: Make Tick unsigned and remove >> UTick) using the option --checkpoint-at-end has been broken. Tracking the >> problem down it seems that in src/python/m5/simulate.py drain() the call >> to >> simulate somehow is passing curTick()-1 to the event queue which causes an >> assert error in src/sim/eventq.hh schedule(). >> >> It can be reproduced by running: >> >> cascade:gem5>build/X86_MESI_CMP_directory/gem5.debug configs/example/se.py >> -c tests/test-progs/hello/bin/x86/linux/hello --cpu-type=timing --ruby >> --checkpoint-at-end -m 100000 >> gem5 Simulator System. http://gem5.org >> gem5 is copyrighted software; use the --copyright option for details. >> >> gem5 compiled Aug 24 2012 16:26:02 >> gem5 started Aug 27 2012 10:28:15 >> gem5 executing on cascade >> command line: build/X86_MESI_CMP_directory/gem5.debug >> configs/example/se.py -c tests/test-progs/hello/bin/x86/linux/hello >> --cpu-type=timing --ruby --checkpoint-at-end -m 100000 >> Global frequency set at 1000000000000 ticks per second >> warn: CoherentBus system.membus has no snooping ports attached! >> 0: system.remote_gdb.listener: listening for remote gdb #0 on port 7000 >> **** REAL SIMULATION **** >> info: Entering event queue @ 0. Starting simulation... >> Exiting @ tick 100000 because simulate() limit reached >> info: Entering event queue @ 100000. Starting simulation... >> gem5.debug: build/X86_MESI_CMP_directory/sim/eventq.hh:484: void >> EventQueue::schedule(Event*, Tick): Assertion `when >= curTick()' failed. >> >> In this example, using GDB I find that when=curTick()-1 instead of >> curTick() as I would have expected. >> >> I can also reproduce this without the --ruby option, and I think it's a >> problem with any CPU, but I haven't tried to reproduce it with the atomic >> CPU yet. >> >> Could you look into this Andreas? I'm afraid I get lost at the python/C++ >> boundary and can't seem to find where that spurious -1 would be coming >> from. >> >> Thanks, >> Jason >> _______________________________________________ >> 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
