On Mon, 22 Apr 2013, Marco Elver wrote:
On Mon, 22 Apr 2013, Nilay Vaish wrote:Apply the following patch and report what happens with fixed-pipeline run you mentioned above. diff --git a/src/mem/ruby/system/System.cc b/src/mem/ruby/system/System.cc --- a/src/mem/ruby/system/System.cc +++ b/src/mem/ruby/system/System.cc @@ -381,6 +381,7 @@ // Restore eventq head eventq_head = eventq->replaceHead(eventq_head); // Restore curTick and Ruby System's clock + assert(curTick() <= curtick_original); setCurTick(curtick_original); resetClock(); } -- NilayHere is what I get: **** REAL SIMULATION **** info: Entering event queue @ 0. Starting simulation... gem5.opt: build/X86_MESI_CMP_directory/mem/ruby/system/System.cc:384: virtual void RubySystem::startup(): Assertion `curTick() <= curtick_original' failed. Program aborted at cycle 18446744073709551615
I was expecting this assertion to fail. It means that the time by which Ruby managed to restore the state of the system was greater than the time when the state of the system was initially recorded. Now, this might sound strange to you. If you are interested in fixing this, you can read the code and figure out how ruby checkpoints and restores state.
To fix the problem, you can try calling enqueueNextFetchRequest() multiple times in the function RubySystem::RubyEvent::process().
-- Nilay _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
