This patch corrects the problem: http://reviews.gem5.org/r/1361/
Sorry for the spam. -Tony On Mon, Aug 27, 2012 at 11:54 AM, Anthony Gutierrez <[email protected]>wrote: > 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
