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
