Never mind, I figured out what the problem was.

Thanks.


On Fri, Sep 13, 2013 at 6:06 PM, Mahshid Sedghi <[email protected]>wrote:

> Hi,
>
> I have a similar problem, but I double check that I restore from the right
> checkpoint. I'd like to checkpoint with fs.py and 1BG memory (using
> mem-size option), and then restore with ruby_fs.py. But upon restoration,
> gem5 tells me that it is expecting 128MB:
>
> fatal: Memory range size has changed! Saw 1073741824, expected 134217728
>
> Do I miss something?
>
> Thanks.
>
>
>
>
>
> On Fri, Oct 19, 2012 at 5:09 PM, David Roberts <[email protected]
> > wrote:
>
>> Thanks, I was using the wrong checkpoint file.
>>
>> On Oct 19, 2012, at 11:35 AM, Nilay Vaish wrote:
>>
>> > David, are you sure that you are using the correct checkpoint? The
>> checkpoint '-r 1' may have been created using a different configuration.
>> >
>> > --
>> > Nilay
>> >
>> > On Fri, 19 Oct 2012, Andreas Hansson wrote:
>> >
>> >> Hi Dave,
>> >>
>> >> Is this using the latest trunk?
>> >>
>> >> Thanks,
>> >>
>> >> Andreas
>> >>
>> >> From: David Roberts <[email protected]<mailto:
>> [email protected]>>
>> >> Reply-To: gem5 users mailing list <[email protected]<mailto:
>> [email protected]>>
>> >> Date: Friday, 19 October 2012 15:18
>> >> To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:
>> [email protected]>>, gem5 users mailing list <[email protected]<mailto:
>> [email protected]>>
>> >> Subject: Re: [gem5-users] ARM Checkpoint restore segfault
>> >>
>> >> Thanks Ali,
>> >>
>> >> On a related issue, I tried checkpointing and restoring with atomic
>> CPU both times and get a memory range difference error on restore.  Is this
>> a checkpointing bug?  Output below.  Thanks
>> >>
>> >> Dave
>> >>
>> >> Create checkpoint:
>> >>
>> >> ./build/ARM/gem5.opt configs/example/fs.py -n 1
>> --kernel=vmlinux.arm.smp.fb.2.6.38.8 --cpu-type=atomic --clock=2.5GHz
>> --script=dave.rcS
>> >>
>> >> Load checkpoint:
>> >>
>> >> ./build/ARM/gem5.opt configs/example/fs.py -n 1
>> --kernel=vmlinux.arm.smp.fb.2.6.38.8 --cpu-type=atomic --clock=2.5GHz
>> --script=dave.rcS -r 1
>> >>
>> >> fatal: Memory range size has changed! Saw 67108864, expected 268435456
>> >> @ cycle 1973295712800
>> >> [unserializeStore:build/ARM/mem/physical.cc, line 406]
>> >> Memory Usage: 315256 KBytes
>> >>
>> >>
>> >>
>> >> On Oct 18, 2012, at 11:40 AM, Ali Saidi wrote:
>> >>
>> >>
>> >> Hi Dave,
>> >>
>> >> It looks like the second system doesn't have a tlb (this=0x0) in the
>> #0 frame.
>> >>
>> >>
>> >>
>> >> Thanks,
>> >>
>> >> Ali
>> >>
>> >> On 18.10.2012 11:14, David Roberts wrote:
>> >>
>> >> Hello,
>> >>
>> >> I'm using the latest development repository and ran into a problem
>> when restoring checkpoints.  I create the checkpoint in atomic mode, then
>> restore it with detailed mode, which instantly segfaults.  Any advice would
>> be appreciated;
>> >>
>> >> 1) creating checkpoint
>> >>
>> >> ./build/ARM/gem5.opt configs/example/fs.py -n 1
>> --kernel=vmlinux-3.3-arm-vexpress-emm-pcie --machine-type=VExpress_EMM
>> --cpu-type=atomic --clock=2.5GHz --script=test.rcS
>> >>
>> >> 2) restoring from checkpoint in detailed mode
>> >>
>> >> ./build/ARM/gem5.debug configs/example/fs.py -n 1
>> --kernel=vmlinux-3.3-arm-vexpress-emm-pcie --machine-type=VExpress_EMM
>> --restore-with-cpu=detailed --caches --clock=2.5GHz --script=test.rcS -r 1
>> >>
>> >> Error message when run in gdb;
>> >>
>> >> Program received signal SIGSEGV, Segmentation fault.
>> >> 0x000000000046c9e2 in ArmISA::TLB::invalidateMiscReg (this=0x0) at
>> build/ARM/arch/arm/tlb.hh:258
>> >> 258         inline void invalidateMiscReg() { miscRegValid = false; }
>> >> (gdb) bt
>> >> #0  0x000000000046c9e2 in ArmISA::TLB::invalidateMiscReg (this=0x0) at
>> build/ARM/arch/arm/tlb.hh:258
>> >> #1  0x00000000004c573e in ArmISA::copyRegs (src=0x3b8fe20,
>> dest=0x3ec5eb0) at build/ARM/arch/arm/utility.cc:159
>> >> #2  0x000000000144b701 in SimpleThread::copyArchRegs (this=0x2adbd20,
>> src_tc=0x3b8fe20) at build/ARM/cpu/simple_thread.cc:265
>> >> #3  0x000000000144ab2f in SimpleThread::copyState (this=0x2adbd20,
>> oldContext=0x3b8fe20) at build/ARM/cpu/simple_thread.cc:165
>> >> #4  0x000000000144aa7b in SimpleThread::copyTC (this=0x2adbd20,
>> context=0x3b8fe20) at build/ARM/cpu/simple_thread.cc:146
>> >> #5  0x000000000149ad94 in FullO3CPU<O3CPUImpl>::unserialize
>> (this=0x3b33110, cp=0x49f8750, section=...) at build/ARM/cpu/o3/cpu.cc:1115
>> >> #6  0x0000000001ac2665 in SimObject::loadState (this=0x3b33110,
>> cp=0x49f8750) at build/ARM/sim/sim_object.cc:83
>> >> #7  0x0000000001ea591f in _wrap_SimObject_loadState (args=0x2e21ef0)
>> at build/ARM/python/m5/internal/param_SimObject_wrap.cc:3039
>> >> #8  0x00002aaaaab4b1e8 in PyObject_Call (func=0x2aaaaaee3908,
>> arg=0x2e21ef0, kw=0x0) at Objects/abstract.c:2487
>> >> #9  0x00002aaaaabe25dc in ext_do_call (f=0x480d320, throwflag=<value
>> optimized out>) at Python/ceval.c:3978
>> >> #10 PyEval_EvalFrameEx (f=0x480d320, throwflag=<value optimized out>)
>> at Python/ceval.c:2410
>> >> #11 0x00002aaaaabe673f in PyEval_EvalCodeEx (co=0x2aaaaaffe558,
>> globals=<value optimized out>, locals=<value optimized out>,
>> args=0x32dbfa8, argcount=2, kws=0x32dbfb8, kwcount=0, defs=0x0, defcount=0,
>> closure=0x0) at Python/ceval.c:2942
>> >> #12 0x00002aaaaabe4517 in call_function (f=0x32dbde0, throwflag=<value
>> optimized out>) at Python/ceval.c:3775
>> >> #13 PyEval_EvalFrameEx (f=0x32dbde0, throwflag=<value optimized out>)
>> at Python/ceval.c:2370
>> >> #14 0x00002aaaaabe673f in PyEval_EvalCodeEx (co=0x2cedd50,
>> globals=<value optimized out>, locals=<value optimized out>,
>> args=0x3809940, argcount=1, kws=0x3809948, kwcount=0, defs=0x32d07e8,
>> defcount=1, closure=0x0)
>> >>   at Python/ceval.c:2942
>> >> #15 0x00002aaaaabe4517 in call_function (f=0x38096c0, throwflag=<value
>> optimized out>) at Python/ceval.c:3775
>> >> #16 PyEval_EvalFrameEx (f=0x38096c0, throwflag=<value optimized out>)
>> at Python/ceval.c:2370
>> >> #17 0x00002aaaaabe4e26 in call_function (f=0x37bacb0, throwflag=<value
>> optimized out>) at Python/ceval.c:3765
>> >> #18 PyEval_EvalFrameEx (f=0x37bacb0, throwflag=<value optimized out>)
>> at Python/ceval.c:2370
>> >> #19 0x00002aaaaabe673f in PyEval_EvalCodeEx (co=0x2d8d378,
>> globals=<value optimized out>, locals=<value optimized out>, args=0x0,
>> argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at
>> Python/ceval.c:2942
>> >> #20 0x00002aaaaabe6782 in PyEval_EvalCode (co=0x0,
>> globals=0x7fffffffa459, locals=0x144da20) at Python/ceval.c:515
>> >> #21 0x00002aaaaabe5576 in exec_statement (f=0x361d850,
>> throwflag=<value optimized out>) at Python/ceval.c:4360
>> >> #22 PyEval_EvalFrameEx (f=0x361d850, throwflag=<value optimized out>)
>> at Python/ceval.c:1706
>> >> #23 0x00002aaaaabe673f in PyEval_EvalCodeEx (co=0x2d2c8a0,
>> globals=<value optimized out>, locals=<value optimized out>, args=0x0,
>> argcount=0, kws=0x2db43c0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at
>> Python/ceval.c:2942
>> >> #24 0x00002aaaaabe4517 in call_function (f=0x2db4240, throwflag=<value
>> optimized out>) at Python/ceval.c:3775
>> >> #25 PyEval_EvalFrameEx (f=0x2db4240, throwflag=<value optimized out>)
>> at Python/ceval.c:2370
>> >> #26 0x00002aaaaabe673f in PyEval_EvalCodeEx (co=0x2d8d3f0,
>> globals=<value optimized out>, locals=<value optimized out>, args=0x0,
>> argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at
>> Python/ceval.c:2942
>> >> #27 0x00002aaaaabe6782 in PyEval_EvalCode (co=0x0,
>> globals=0x7fffffffa459, locals=0x144da20) at Python/ceval.c:515
>> >> #28 0x00002aaaaac076c9 in run_mod (str=0x20eac33 "m5.main()",
>> start=<value optimized out>, globals=0x2b647b0, locals=0x2b647b0,
>> flags=0x0) at Python/pythonrun.c:1330
>> >> #29 PyRun_StringFlags (str=0x20eac33 "m5.main()", start=<value
>> optimized out>, globals=0x2b647b0, locals=0x2b647b0, flags=0x0) at
>> Python/pythonrun.c:1293
>> >> #30 0x0000000001a82de8 in m5Main (argc=12, argv=0x7fffffffbcd8) at
>> build/ARM/sim/init.cc:256
>> >> #31 0x000000000040a81b in main (argc=12, argv=0x7fffffffbcd8) at
>> build/ARM/sim/main.cc:57
>> >> _______________________________________________
>> >> gem5-users mailing list
>> >> [email protected]<mailto:[email protected]>
>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> gem5-users mailing list
>> >> [email protected]<mailto:[email protected]>
>> >> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>> >>
>> >>
>> >> -- 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-users mailing list
>> >> [email protected]
>> >> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>> >>
>> > _______________________________________________
>> > gem5-users mailing list
>> > [email protected]
>> > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>
>> _______________________________________________
>> gem5-users mailing list
>> [email protected]
>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>
>
>
_______________________________________________
gem5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

Reply via email to