Re: [gem5-users] Issue with page table allocate when restoring from checkpoint

[Jason Lowe-Power]

Hi Ruohuang,

We all would really appreciate it if you would create a patch and submit it
to the code review site: https://gem5-review.googlesource.com. Steps on how
to get started can be found here:
https://gem5.googlesource.com/public/gem5/+/master/CONTRIBUTING.md.

Once you submit the patch you'll receive reviews (probably pretty quickly,
and likely from me and Gabe). Then, once we give you positive reviews, you
can submit the patch yourself via gerrit!

I'm looking forward to your contribution!

Cheers,
Jason

---
Jason Lowe-Power
Assistant Professor, Computer Science Department
University of California, Davis
https://faculty.engineering.ucdavis.edu/lowepower/


On Thu, Nov 16, 2017 at 1:22 PM Ruohuang Zheng 
wrote:

> Hi,
>
> This is because of address space info is not saved during serialization.
>
> In src/sim/process.cc,
>
> In void Process::serialize(CheckpointOut ) const, add the following
> lines
>
> paramOut(cp, "mem_state.brk_point", memState->getBrkPoint());
> paramOut(cp, "mem_state.stack_base", memState->getStackBase());
> paramOut(cp, "mem_state.stack_size", memState->getStackSize());
> paramOut(cp, "mem_state.max_stack_size", memState->getMaxStackSize());
> paramOut(cp, "mem_state.stack_min", memState->getStackMin());
> paramOut(cp, "mem_state.next_thread_stack_base",
> memState->getNextThreadStackBase());
> paramOut(cp, "mem_state.mmap_end", memState->getMmapEnd());
>
>
> In void Process::unserialize(CheckpointIn ), add the following lines
>
> Addr _brkPoint;
> Addr _stackBase;
> Addr _stackSize;
> Addr _maxStackSize;
> Addr _stackMin;
> Addr _nextThreadStackBase;
> Addr _mmapEnd;
>
> paramIn(cp, "mem_state.brk_point", _brkPoint);
> paramIn(cp, "mem_state.stack_base", _stackBase);
> paramIn(cp, "mem_state.stack_size", _stackSize);
> paramIn(cp, "mem_state.max_stack_size", _maxStackSize);
> paramIn(cp, "mem_state.stack_min", _stackMin);
> paramIn(cp, "mem_state.next_thread_stack_base", _nextThreadStackBase);
> paramIn(cp, "mem_state.mmap_end", _mmapEnd);
>
> memState->setBrkPoint(_brkPoint);
> memState->setStackBase(_stackBase);
> memState->setStackSize(_stackSize);
> memState->setMaxStackSize(_maxStackSize);
> memState->setStackMin(_stackMin);
> memState->setNextThreadStackBase(_nextThreadStackBase);
> memState->setMmapEnd(_mmapEnd);
>
>
> On Mon, Nov 13, 2017 at 9:33 PM, Gabe Black  wrote:
>
>> Hi Austin. It sounds like some sort of bug in the Process object or
>> FuncPageTable object's serialization code, although that's just a guess on
>> my part. If it works in an older version of gem5, you could try binary
>> searching through the history and find the point where it stopped working.
>> I took a quick look at the existing implementation and didn't see anything
>> that was obviously wrong.
>>
>> Gabe
>>
>> On Mon, Nov 13, 2017 at 3:28 PM, Austin Harris 
>> wrote:
>>
>>> Hello,
>>>
>>> I've been running into an issue with the latest gem5 git master when
>>> running gobmk from spec2006. The issue occurs when restoring from a
>>> checkpoint that I created by adding m5_checkpoint to the gobmk source
>>> (specifically right before the switch(playmode) in interface/main.c.) If I
>>> let the simulation run from the beginning rather than restoring from a
>>> checkpoint, the error never occurs.
>>>
>>> I run the following command to generate the checkpoint:
>>>
>>> ../build/ARM/gem5.opt ../configs/example/se.py
>>> --cpu-type=AtomicSimpleCPU --mem-size=4GB --mem-type=SimpleMemory
>>> --cpu-clock=1GHz --sys-clock=1GHz -c ./gobmk_base.aarch64-linux-gnu -o '
>>> --quiet --mode gtp ' --input=13x13.tst
>>>
>>> And this command to restore from the checkpoint:
>>>  ../build/ARM/gem5.opt ../configs/example/se.py --cpu-type=O3_ARM_v7a_3
>>> --caches --l2cache --mem-size=4GB --mem-type=SimpleMemory --cpu-clock=1GHz
>>> --sys-clock=1GHz --l1d_size=32kB -r1 -c ./gobmk_base.aarch64-linux-gnu -o '
>>> --quiet --mode gtp ' --input=13x13.tst
>>>
>>>
>>> Once I restore from the checkpoint and begin simulating, I get the below
>>> error:
>>> fatal: FuncPageTable::allocate: addr 0x3f already mapped
>>>
>>> I tried the same experiment with x86 and RISC-V and all got the already
>>> mapped error. I also tried MinorCPU and TimingSimpleCPU to no avail.
>>>
>>> However, if I checkout the 2015_09_03 tag, I am able to successfully
>>> restore and run the same binary without error.
>>>
>>> I noticed there was some refactoring of serialize added here in between
>>> the working tag and the latest master: http://reviews.gem5.org/r/2861,
>>> however I wasn't able to narrow down what could be causing the issue.
>>>
>>> I tried the suggestion to print out the Syscall debug flags here:
>>> https://www.mail-archive.com/gem5-users@gem5.org/msg13627.html, however
>>> the output just shows that mmap is being called with that range:

Re: [gem5-users] Issue with page table allocate when restoring from checkpoint

[Ruohuang Zheng]

Hi,

This is because of address space info is not saved during serialization.

In src/sim/process.cc,

In void Process::serialize(CheckpointOut ) const, add the following lines

paramOut(cp, "mem_state.brk_point", memState->getBrkPoint());
paramOut(cp, "mem_state.stack_base", memState->getStackBase());
paramOut(cp, "mem_state.stack_size", memState->getStackSize());
paramOut(cp, "mem_state.max_stack_size", memState->getMaxStackSize());
paramOut(cp, "mem_state.stack_min", memState->getStackMin());
paramOut(cp, "mem_state.next_thread_stack_base",
memState->getNextThreadStackBase());
paramOut(cp, "mem_state.mmap_end", memState->getMmapEnd());


In void Process::unserialize(CheckpointIn ), add the following lines

Addr _brkPoint;
Addr _stackBase;
Addr _stackSize;
Addr _maxStackSize;
Addr _stackMin;
Addr _nextThreadStackBase;
Addr _mmapEnd;

paramIn(cp, "mem_state.brk_point", _brkPoint);
paramIn(cp, "mem_state.stack_base", _stackBase);
paramIn(cp, "mem_state.stack_size", _stackSize);
paramIn(cp, "mem_state.max_stack_size", _maxStackSize);
paramIn(cp, "mem_state.stack_min", _stackMin);
paramIn(cp, "mem_state.next_thread_stack_base", _nextThreadStackBase);
paramIn(cp, "mem_state.mmap_end", _mmapEnd);

memState->setBrkPoint(_brkPoint);
memState->setStackBase(_stackBase);
memState->setStackSize(_stackSize);
memState->setMaxStackSize(_maxStackSize);
memState->setStackMin(_stackMin);
memState->setNextThreadStackBase(_nextThreadStackBase);
memState->setMmapEnd(_mmapEnd);


On Mon, Nov 13, 2017 at 9:33 PM, Gabe Black  wrote:

> Hi Austin. It sounds like some sort of bug in the Process object or
> FuncPageTable object's serialization code, although that's just a guess on
> my part. If it works in an older version of gem5, you could try binary
> searching through the history and find the point where it stopped working.
> I took a quick look at the existing implementation and didn't see anything
> that was obviously wrong.
>
> Gabe
>
> On Mon, Nov 13, 2017 at 3:28 PM, Austin Harris 
> wrote:
>
>> Hello,
>>
>> I've been running into an issue with the latest gem5 git master when
>> running gobmk from spec2006. The issue occurs when restoring from a
>> checkpoint that I created by adding m5_checkpoint to the gobmk source
>> (specifically right before the switch(playmode) in interface/main.c.) If I
>> let the simulation run from the beginning rather than restoring from a
>> checkpoint, the error never occurs.
>>
>> I run the following command to generate the checkpoint:
>>
>> ../build/ARM/gem5.opt ../configs/example/se.py --cpu-type=AtomicSimpleCPU
>> --mem-size=4GB --mem-type=SimpleMemory --cpu-clock=1GHz --sys-clock=1GHz -c
>> ./gobmk_base.aarch64-linux-gnu -o ' --quiet --mode gtp ' --input=13x13.tst
>>
>> And this command to restore from the checkpoint:
>>  ../build/ARM/gem5.opt ../configs/example/se.py --cpu-type=O3_ARM_v7a_3
>> --caches --l2cache --mem-size=4GB --mem-type=SimpleMemory --cpu-clock=1GHz
>> --sys-clock=1GHz --l1d_size=32kB -r1 -c ./gobmk_base.aarch64-linux-gnu -o '
>> --quiet --mode gtp ' --input=13x13.tst
>>
>>
>> Once I restore from the checkpoint and begin simulating, I get the below
>> error:
>> fatal: FuncPageTable::allocate: addr 0x3f already mapped
>>
>> I tried the same experiment with x86 and RISC-V and all got the already
>> mapped error. I also tried MinorCPU and TimingSimpleCPU to no avail.
>>
>> However, if I checkout the 2015_09_03 tag, I am able to successfully
>> restore and run the same binary without error.
>>
>> I noticed there was some refactoring of serialize added here in between
>> the working tag and the latest master: http://reviews.gem5.org/r/2861,
>> however I wasn't able to narrow down what could be causing the issue.
>>
>> I tried the suggestion to print out the Syscall debug flags here:
>> https://www.mail-archive.com/gem5-users@gem5.org/msg13627.html, however
>> the output just shows that mmap is being called with that range:
>> 12384702000: system.switch_cpus: T0 : syscall mmap2 called w/arguments 0,
>> 65536, 3, 34, 18446744073709551615, 0
>> 12384702000: system.switch_cpus: T0 : syscall  mmap range is 0x3f
>> - 0x3f
>>
>> I also tried larger memory sizes up to 16GB as well as changing the
>> maxStackSize in sim/Process.py and max_stack_size in arch/arm/process.cc to
>> 128MB, but the same error persists.
>>
>> Does anyone have any pointers for how to debug this issue, or has anyone
>> else had similar issues with gobmk or other spec2006 benchmarks?
>>
>> Thanks!
>> Austin
>>
>> ___
>> gem5-users mailing list
>> gem5-users@gem5.org
>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>
>
>
> ___
> gem5-users mailing list
> gem5-users@gem5.org
> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>

[gem5-users] simulate() limit problem

[liuchen]

Hello:
while i was running splash2 Alpha on gem5 alpha se multicore mode,I always 
have a "Existing tick 18446744073709551615 simulate() limit reached" problem.
I changed simulate.cc to shadow the limit_event,but it didn't work,it will 
cause core dumped.splash2 i used is from the gem5 website.

Does anyone know what the problem is?___
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users