Hey Tony, That fixes it, thanks!
Jason On Mon, Aug 27, 2012 at 10:59 AM, Anthony Gutierrez <[email protected]>wrote: > 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 > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
