I'm not a fast-forwarding wiz myself (Lisa?), but it loooks like if things arent working you are getting to have to get your hands dirty in the code and figure the internals of how fast forwarding is supposed to work, so you can get fix the problem.
Once you start looking at code and debugging, it might be a good idea to send emails to m5-dev, so that once you detect the problem, a patch can be generated and the repo can be updated. Alternatively, check the mailing list archives as I'm sure there have been people asking about fast forwarding in the past... On Tue, Nov 10, 2009 at 6:51 PM, Sujay Phadke <[email protected]>wrote: > Hi Steve, > Here is a run with unmodified m5-stable using se.py > > spha...@lowpower:~/research/m5/m5-stable$ ./build/ALPHA_SE/m5.opt > configs/example/se.py -d --caches --l2cache --fast-forward=1 > > M5 Simulator System > > Copyright (c) 2001-2008 > The Regents of The University of Michigan > All Rights Reserved > > > M5 compiled Nov 8 2009 21:09:22 > M5 revision 15e5581286b6+ 6285+ default tip > M5 started Nov 10 2009 18:44:15 > M5 executing on lowpower > command line: ./build/ALPHA_SE/m5.opt configs/example/se.py -d --caches > --l2cache --fast-forward=1 > Global frequency set at 1000000000000 ticks per second > 0: system.remote_gdb.listener: listening for remote gdb #0 on port 7000 > Switch at instruction count:1 > info: Entering event queue @ 0. Starting simulation... > hack: be nice to actually delete the event here > Switched CPUS @ cycle = 1000 > Changing memory mode to timing > switching cpus > m5.opt: build/ALPHA_SE/cpu/o3/thread_context_impl.hh:57: void > O3ThreadContext< <template-parameter-1-1> > >::takeOverFrom(ThreadContext*) [with Impl = O3CPUImpl]: Assertion > `getSystemPtr() == old_context->getSystemPtr()' failed. > Program aborted at cycle 1000 > Aborted > > I get the same error. I also tried giving the "-s" for standard switch > and changing the value of FF. Any idea why this is happening? > > Thanks, > > Sujay > On Tue, 2009-11-10 at 15:30 -0800, Steve Reinhardt wrote: > > I don't know any details about what works and what doesn't off the top > > of my head, but I can tell you that if something "works" in m5.fast > > but hits an assertion error in m5.opt, that's only because assertions > > are compiled out in m5.fast. So either the assertion is asserting > > something that doesn't necessarily need to be true (which happens) or > > the assertion is valid and m5.fast is merrily proceeding to do > > something bogus that just happens not to crash the simulation. > > > > That particular assertion looks like it should hold; what it is saying > > is that you're substituting a detailed CPU in system A for a simple > > CPU in system B, which would possibly cause problems if the CPU ever > > did something based on the system it's a member of. That could be a > > configuration error. > > > > Steve > > > > On Tue, Nov 10, 2009 at 12:00 PM, Sujay Phadke <[email protected]> > wrote: > > > Does any one know about this? Is FF working with the latest m5.opt in > SE > > > mode, and is it possible to FF with multiple CPUS? > > > > > > Thanks, > > > Sujay > > > > > > ----- Original Message ----- > > > From: "Sujay Phadke" <[email protected]> > > > To: <[email protected]> > > > Sent: Saturday, November 07, 2009 5:41 PM > > > Subject: [m5-users] fast-forwarding and switching cpus > > > > > > > > >> Hello, > > >> I was going through the previous threads about fastforwarding > > >> support, but couldnt get a clear answer. When we specify > > >> --fast-forward=FF, is if FF ticks or FF instructions? If it is ticks, > > >> then is there a new way for FF instructions? > > >> > > >> As an aside, I am able to use --fast-forward with m5.fast. With > m5.opt, > > >> it crashes with the error: > > >> > > >> M5 compiled Nov 6 2009 17:34:43 > > >> M5 revision 15e5581286b6 6285 default tip > > >> M5 started Nov 7 2009 17:40:10 > > >> M5 executing on lowpower > > >> command line: ./build/ALPHA_SE/m5.opt -d ../output/test/ > > >> configs/spec2k6/runspec2k6.py -b bzip2 -d --caches --l2cache > > >> --fast-forward=5000000 --max-inst=100000 > > >> Global frequency set at 1000000000000 ticks per second > > >> 0: system.remote_gdb.listener: listening for remote gdb #0 on port > 7000 > > >> Switch at instruction count:5000000 > > >> info: Entering event queue @ 0. Starting simulation... > > >> info: Increasing stack size by one page. > > >> hack: be nice to actually delete the event here > > >> Switched CPUS @ cycle = 5079299000 > > >> switching cpus > > >> m5.opt: build/ALPHA_SE/cpu/o3/thread_context_impl.hh:57: void > > >> O3ThreadContext< <template-parameter-1-1> > > >>>::takeOverFrom(ThreadContext*) [with Impl = O3CPUImpl]: Assertion > > >> `getSystemPtr() == old_context->getSystemPtr()' failed. > > >> Program aborted at cycle 5079299000 > > >> Aborted > > >> > > >> Is there still the same bug about no valid threadcontext in o3? > > >> > > >> - Sujay > > >> > > >> > > >> _______________________________________________ > > >> m5-users mailing list > > >> [email protected] > > >> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users > > >> > > > > > > _______________________________________________ > > > m5-users mailing list > > > [email protected] > > > http://m5sim.org/cgi-bin/mailman/listinfo/m5-users > > > > > _______________________________________________ > > m5-users mailing list > > [email protected] > > http://m5sim.org/cgi-bin/mailman/listinfo/m5-users > > _______________________________________________ > m5-users mailing list > [email protected] > http://m5sim.org/cgi-bin/mailman/listinfo/m5-users > -- - Korey
_______________________________________________ m5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
