Great to hear. Glad that one is sorted :) Thanks again Tony for fixing it On 27/08/2012 09:15, "Jason Power" <[email protected]> wrote:
>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 > -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
