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
