[gem5-users] Re: gem5 encountered a segmentation fault when I running Arm FS mode

[Mr.Rich via gem5-users]

Hi Giacomo,


Thanks for your reply. According to your guidance, I have solved my problem!


Best Wishes,


Chao


--Original--
From:   
 "gem5 users mailing list"  
  
http://www.gem5.org/documentation/general_docs/fullsystem/building_arm_kernel . 
And I download image from: 
http://dist.gem5.org/dist/current/arm/disks/linaro-minimal-aarch64.img.bz2

What I'm curious about here is that I set the number of cpus when I was running 
FS mode to be three, but why did the program only recognize one ?

I can run this benchmark successfully in SE mode, so I think the benchmark 
should be fine. I guess maybe the kernel, image or parameters I used are wrong.

I'm looking forward to your help! Thank you in advance !

The following are some message of gem5 during operation.

1086032148000: system.terminal: attach terminal 0
gem5 has encountered a segmentation fault!

--- BEGIN LIBC BACKTRACE ---
build/ARM_MESI_Three_Level_HTM/gem5.opt(_Z15print_backtracev+0x30)[0x5613bc840440]
build/ARM_MESI_Three_Level_HTM/gem5.opt(+0x159d7e5)[0x5613bc8547e5]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x153c0)[0x7fae9bf593c0]
build/ARM_MESI_Three_Level_HTM/gem5.opt(_ZN15TimingSimpleCPU14completeIfetchEP6Packet+0x157)[0x5613bd789fb7]
build/ARM_MESI_Three_Level_HTM/gem5.opt(_ZN10EventQueue10serviceOneEv+0x13d)[0x5613bc84853d]
build/ARM_MESI_Three_Level_HTM/gem5.opt(_Z9doSimLoopP10EventQueue+0xf8)[0x5613bc869d68]
build/ARM_MESI_Three_Level_HTM/gem5.opt(_Z8simulatem+0xaed)[0x5613bc86ab5d]
build/ARM_MESI_Three_Level_HTM/gem5.opt(+0x14adf80)[0x5613bc764f80]
build/ARM_MESI_Three_Level_HTM/gem5.opt(+0xe5f8f7)[0x5613bc1168f7]
/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x6372)[0x7fae9c07bff2]
/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x7f8)[0x7fae9c075628]
/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x6f81)[0x7fae9c07cc01]
/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x7f8)[0x7fae9c075628]
/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x6f81)[0x7fae9c07cc01]
/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x7f8)[0x7fae9c075628]
/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x6f81)[0x7fae9c07cc01]
/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x7f8)[0x7fae9c075628]
/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCode+0x19)[0x7fae9c075b39]
/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x6e76)[0x7fae9c07caf6]
/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x7f8)[0x7fae9c075628]
/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x6f81)[0x7fae9c07cc01]
/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x7f8)[0x7fae9c075628]
/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCode+0x19)[0x7fae9c075b39]
/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyRun_StringFlags+0x76)[0x7fae9c04e846]
build/ARM_MESI_Three_Level_HTM/gem5.opt(_Z6m5MainiPPc+0x8b)[0x5613bc85275b]
build/ARM_MESI_Three_Level_HTM/gem5.opt(main+0x4c)[0x5613bbea522c]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0x7fae9b5160b3]
build/ARM_MESI_Three_Level_HTM/gem5.opt(_start+0x2e)[0x5613bbed639e]
--- END LIBC BACKTRACE ---
./run-this.sh: line 28: 7 Segmentation fault
(core dumped) build/ARM_MESI_Three_Level_HTM/gem5.opt 
configs/example/fs.py --ruby --num-cpus=3 \ --cpu-type=TimingSimpleCPU 
--kernel=../system/vmlinux --machine-type=VExpress_GEM5_V1 \ 
--dtb-file=./system/arm/dt/armv8_gem5_v1_1cpu.dtb 
--disk-image=linaro-minimal-aarch64.img \
--bootloader=./system/arm/bootloader/arm64/boot_v2.arm64
___
gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to 
gem5-users-le...@gem5.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
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 -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: SE Mode and Std::thread

[Daniel Gerzhoy via gem5-users]

Ciro,

When I merged the changes in from that patch and its relations I started
getting a crash instead of a hang. That crash, I can reproduce on develop.

gem5.opt: build/X86/cpu/o3/cpu.cc:823: void
FullO3CPU::removeThread(ThreadID)
[with Impl = O3CPUImpl; ThreadID = short int]: Assertion
`commit.rob->isEmpty(tid)' failed.

Check out the gem5-users thread from last week:
  [gem5-users] gem5 pthread regression with O3CPU on x86?

Incidentally this highlights the need for a slack or something like that
for gem5-users/develop where we can tag people etc.

Anyway:

 I am working on a fix and will open a ticket. Apparently it works ok
on ARM, Derrick Greenspan ran it.. Not sure what that means, it might just
happen to be that the ROB is empty when the ARM core is halted, I think
that the flaw is in the cpu code itself. (See my description in that
thread).

Dan

On Mon, Nov 2, 2020 at 7:19 AM Ciro Santilli  wrote:

> Daniel, if you manage to reproduce on clean develop, please also open an
> issue at https://gem5.atlassian.net/jira/software/c/projects/GEM5/issues I'd
> also be curious to see if it reproduces on se.py (so I could see if it also
> happens on ARM).
>
> We've had some ARM-specific SE issues e.g. at
> https://gem5.atlassian.net/browse/GEM5-537 but this is X86 so I'm not
> sure. With SyscallAll + ExecAll and some patience most bugs can be found.
> Presumably new instructions are being run in an infinite loop, otherwise
> simulation would reach the end of time. So I would try to determine what
> that minimal loop is and why it won't exit.
> --
> *From:* Daniel Gerzhoy via gem5-users 
> *Sent:* Wednesday, October 28, 2020 7:21 PM
> *To:* gem5 users mailing list 
> *Cc:* Daniel Gerzhoy 
> *Subject:* [gem5-users] Re: SE Mode and Std::thread
>
> Looks like this is related to this change:
>
> https://gem5-review.googlesource.com/c/public/gem5/+/8184
>
> I'm a bit behind develop because of custom changes and don't have this
> patch merged yet.
> Cherry picking this might work, but merging would probably be the best
> solution, if time consuming.
>
> Cheers,
> Dan
>
>
> On Tue, Oct 27, 2020 at 3:39 PM Daniel Gerzhoy 
> wrote:
>
> Hey all,
>
> I'm running into a strange issue where threads are not spawning when
> launched with std::thread. It seems to work once, and then I try to launch
> again using a newly allocated thread pointer (after deleting the old one)
> and it hangs.
>
> Minimal example:
>
> void foo()
> {
>   printf("Foo alive from tid %lu\n", m5_cpu_id());
>   //m5_cpu_id is a pseudo_instruction I added to return tc->cpuId()
> }
>
> void main()
> {
>   printf("Launching foo 1"\n);
>   std::thread * mythread = new std::thread(foo,...);
>   printf("Done Launching foo 1"\n);
>
>   printf("Joining foo 1"\n);
>   myThread->join();
>   delete myThread;
>
>   printf("Launching foo 2"\n);
>   mythread = new std::thread(foo,...);
>   printf("Done Launching foo 2"\n);
>
>   printf("Joining foo 2"\n);
>   myThread->join(); //< IT HANGS HERE
>   printf("Done Everything!\n");
>   delete myThread;
> }
>
> __
>
> It works fine with TimingSimpleCPU, but then with DerivO3CPU I get the
> failure.
>
> Output for  DerivO3CPU:
>   Launch 1
>   Done Launch 1
>   I'm alive on tid 1
>   Launch 2
>   Done Launch 2
>
> And there it Hangs.
>
> FYI I am using apu_se.py, though with the above minimal example I've
> managed to reproduce the bug with no GPU code (nor even hipcc) involved.
>
> I went back to the original code I found that showed std::thread could be
> used here:
> https://www.gem5.org/documentation/learning_gem5/part3/running/
>
> [image: image.png]
>
> The comment there that -1 is required for SE mode, and then the subsequent
> comment about appeasing SE mode...
>
> What exactly do those comments mean?
>
> I'm going to keep debugging, but if anyone has any suggestions for debug
> flags that could be helpful it would be appreciated. (I'm using SyscallAll
> and going to investigate some of the syscalls SE mode ignores).
>
> I'm wondering if maybe it is calling join() multiple times that might be
> the problem? Though unsure why at this point.
>
> Thanks!
>
> Dan
>
> 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 -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: File sizes of simulators generated by test script are much larger than those built by manual scons commands

[Ciro Santilli via gem5-users]

Yes, I had also previously observed that debug symbols make the huge majority 
of the executable's size, and for some reason much more so in .opt than in 
debug (presumably it takes more information to map back optimized code to 
source).

You can confirm that by using strip gem5.opt or gcc- s during build, which 
leads to binaries of the order of 60Mb.

Related thread: https://gem5.atlassian.net/browse/GEM5-572

From: Liao Xiongfei via gem5-users 
Sent: Friday, October 30, 2020 4:38 PM
To: gem5-users@gem5.org 
Cc: Liao Xiongfei 
Subject: [gem5-users] File sizes of simulators generated by test script are 
much larger than those built by manual scons commands


Hi all,



When I ran the test script under $GEM5/tests using command “python main.py run” 
on a machine previously without any gem5 simulator built, the script built 5 
different gem5.opt simulators before running test suites.



However, the file sizes of the simulators are pretty large, shown below. The 
gem5.opt for RISC-V is 4.4GB and failed with error message “cannot allocate 
memory”.

1.8Gbuild/ARM/gem5.opt

858Mbuild/NULL/gem5.opt

4.4Gbuild/RISCV/gem5.opt

1.5Gbuild/X86/gem5.opt

1.5Gbuild/X86_MSI/gem5.opt



On the other hand, the gem5.debug simulation was built using “scons 
build/RISCV/gem5.debug –j 8” and its size is much smaller.

522Mbuild/RISCV/gem5.debug



Are these caused by different compiler or linker settings?



I was surprised by a large number of failed tests because RISCV gem5.opt could 
not run. Hopefully, this could be fixed somehow. Thanks.


___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: SE Mode and Std::thread

[Ciro Santilli via gem5-users]

Daniel, if you manage to reproduce on clean develop, please also open an issue 
at https://gem5.atlassian.net/jira/software/c/projects/GEM5/issues I'd also be 
curious to see if it reproduces on se.py (so I could see if it also happens on 
ARM).

We've had some ARM-specific SE issues e.g. at 
https://gem5.atlassian.net/browse/GEM5-537 but this is X86 so I'm not sure. 
With SyscallAll + ExecAll and some patience most bugs can be found. Presumably 
new instructions are being run in an infinite loop, otherwise simulation would 
reach the end of time. So I would try to determine what that minimal loop is 
and why it won't exit.

From: Daniel Gerzhoy via gem5-users 
Sent: Wednesday, October 28, 2020 7:21 PM
To: gem5 users mailing list 
Cc: Daniel Gerzhoy 
Subject: [gem5-users] Re: SE Mode and Std::thread

Looks like this is related to this change:

https://gem5-review.googlesource.com/c/public/gem5/+/8184

I'm a bit behind develop because of custom changes and don't have this patch 
merged yet.
Cherry picking this might work, but merging would probably be the best 
solution, if time consuming.

Cheers,
Dan


On Tue, Oct 27, 2020 at 3:39 PM Daniel Gerzhoy 
mailto:daniel.gerz...@gmail.com>> wrote:
Hey all,

I'm running into a strange issue where threads are not spawning when launched 
with std::thread. It seems to work once, and then I try to launch again using a 
newly allocated thread pointer (after deleting the old one) and it hangs.

Minimal example:

void foo()
{
  printf("Foo alive from tid %lu\n", m5_cpu_id());
  //m5_cpu_id is a pseudo_instruction I added to return tc->cpuId()
}

void main()
{
  printf("Launching foo 1"\n);
  std::thread * mythread = new std::thread(foo,...);
  printf("Done Launching foo 1"\n);

  printf("Joining foo 1"\n);
  myThread->join();
  delete myThread;

  printf("Launching foo 2"\n);
  mythread = new std::thread(foo,...);
  printf("Done Launching foo 2"\n);

  printf("Joining foo 2"\n);
  myThread->join(); //< IT HANGS HERE
  printf("Done Everything!\n");
  delete myThread;
}

__

It works fine with TimingSimpleCPU, but then with DerivO3CPU I get the failure.

Output for  DerivO3CPU:
  Launch 1
  Done Launch 1
  I'm alive on tid 1
  Launch 2
  Done Launch 2

And there it Hangs.

FYI I am using apu_se.py, though with the above minimal example I've managed to 
reproduce the bug with no GPU code (nor even hipcc) involved.

I went back to the original code I found that showed std::thread could be used 
here:
https://www.gem5.org/documentation/learning_gem5/part3/running/

[image.png]

The comment there that -1 is required for SE mode, and then the subsequent 
comment about appeasing SE mode...

What exactly do those comments mean?

I'm going to keep debugging, but if anyone has any suggestions for debug flags 
that could be helpful it would be appreciated. (I'm using SyscallAll and going 
to investigate some of the syscalls SE mode ignores).

I'm wondering if maybe it is calling join() multiple times that might be the 
problem? Though unsure why at this point.

Thanks!

Dan
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: How to use the new libm5.a

[Ciro Santilli via gem5-users]

BTW I pushed a patch exposing m5_exit_addr at: 
https://gem5-review.googlesource.com/c/public/gem5/+/36896

And after that this should work on KVM 
https://gem5-review.googlesource.com/c/public/gem5-resources/+/36677/1

From: Gabe Black via gem5-users 
Sent: Wednesday, October 28, 2020 10:48 PM
To: gem5 users mailing list 
Cc: Gabe Black 
Subject: [gem5-users] Re: How to use the new libm5.a

Hi Wenqi. You do still need to call map_m5_mem(), but as you found, now that 
there isn't one baked in call mechanism in the library you need to call the 
version of the function that will use the invocation mechanism you need. The 
header doesn't have declarations for them all, but if you declare your own with 
the same signature and an _addr suffix, you can call that and use the magic 
address based calling mechanism.

Gabe

On Wed, Oct 28, 2020 at 10:49 AM Wenqi Yin via gem5-users 
mailto:gem5-users@gem5.org>> wrote:
Hi Hoa, Gabe,

Thanks for your help! But just want to confirm this: what I did in the past is 
calling map_m5_mem() in my code first and then call specific m5 functions, and 
it seems to work. The guest in running on KvmCPU.

When I am trying to do the same thing with the new libm5.a, it gave an 
exception (Illegal Instruction), however I haven’t looked into the error 
carefully yet, it may just because for some reason the lib is still trying to 
use the magic instruction interface. But before I proceed any further, just 
want to make sure I was using the correct approach to do this.

Best,
Wenqi

On Oct 26, 2020, at 23:30, Gabe Black via gem5-users 
mailto:gem5-users@gem5.org>> wrote:

Hi Wenqi. The updated libm5.a should be used in basically the same way as the 
old version. Just link against the library, include the header file, and call 
into the op you want using the normal function call syntax.

Hoa, the documentation you've linked to is a little out of date. How can it be 
updated?

Gabe

On Sun, Oct 25, 2020 at 9:31 PM Hoa Nguyen via gem5-users 
mailto:gem5-users@gem5.org>> wrote:
Hi Wenqi,

We have some documentation about the new m5 utility here:
https://www.gem5.org/documentation/general_docs/m5ops/

The following link is an example of annotating PARSEC:
https://github.com/darchr/parsec-benchmark/commits/gem5-20-annotations

Regards,
Hoa Nguyen

On 10/25/20, wqyin--- via gem5-users 
mailto:gem5-users@gem5.org>> wrote:
> Hello all,
>
> I noticed the util/m5 has big changes since this
> commit:26454e8072e607d54ac67c42b33355d7c94d6d60 around Apr 27. I am
> wondering how should I use this new interface/implementation to call
> m5ops in my program? Shall I also instantiate a default CallType and
> then use it to obtain the dispatch table and finally pass it to
> Command::run? Also is there any examples which use the new
> implementation to annotate any benchmarks running inside gem5? Thanks
>
> Best,
>
> Wenqi
>
>
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to 
gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to 
gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to 
gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: gem5 encountered a segmentation fault when I running Arm FS mode

[Giacomo Travaglini via gem5-users]

Hi,

>From the command line you posted I can see you are using the following DTB 
>binary:

--dtb-file=./system/arm/dt/armv8_gem5_v1_1cpu.dtb

This is informing the Linux kernel there is one cpu only 
(armv8_gem5_v1_1cpu.dtb). That's why you don't see the other ones.
You should change DTB binary or rely on DTB autogeneration (recommended)

Also you are using the VExpress_GEM5_V1 platform, but the bootloader in use is 
targeting V2:

--bootloader=./system/arm/bootloader/arm64/boot_v2.arm64

You should use the boot.arm64. This might solve your segfault problem

Kind Regards

Giacomo

-Original Message-
From: 605636064--- via gem5-users 
Sent: 31 October 2020 04:24
To: gem5-users@gem5.org
Cc: 605636...@qq.com
Subject: [gem5-users] gem5 encountered a segmentation fault when I running Arm 
FS mode

Hi everyone,

I have been using ARM FS mode of Gem5 recently, and I can boot the system 
successfully.However, when I run my benchmark, I encounter segmentation faults. 
Do you know what's going on?

My gem5 verison is 20.1.0.0 .

I compiled kernel,dtb file and bootloader following the tutorial of this 
website: 
http://www.gem5.org/documentation/general_docs/fullsystem/building_arm_kernel . 
And I download image from: 
http://dist.gem5.org/dist/current/arm/disks/linaro-minimal-aarch64.img.bz2

What I'm curious about here is that I set the number of cpus when I was running 
FS mode to be three, but why did the program only recognize one ?

I can run this benchmark successfully in SE mode, so I think the benchmark 
should be fine. I guess maybe the kernel, image or parameters I used are wrong.

I'm looking forward to your help! Thank you in advance !

The following are some message of gem5 during operation.

1086032148000: system.terminal: attach terminal 0
gem5 has encountered a segmentation fault!

--- BEGIN LIBC BACKTRACE ---
build/ARM_MESI_Three_Level_HTM/gem5.opt(_Z15print_backtracev+0x30)[0x5613bc840440]
build/ARM_MESI_Three_Level_HTM/gem5.opt(+0x159d7e5)[0x5613bc8547e5]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x153c0)[0x7fae9bf593c0]
build/ARM_MESI_Three_Level_HTM/gem5.opt(_ZN15TimingSimpleCPU14completeIfetchEP6Packet+0x157)[0x5613bd789fb7]
build/ARM_MESI_Three_Level_HTM/gem5.opt(_ZN10EventQueue10serviceOneEv+0x13d)[0x5613bc84853d]
build/ARM_MESI_Three_Level_HTM/gem5.opt(_Z9doSimLoopP10EventQueue+0xf8)[0x5613bc869d68]
build/ARM_MESI_Three_Level_HTM/gem5.opt(_Z8simulatem+0xaed)[0x5613bc86ab5d]
build/ARM_MESI_Three_Level_HTM/gem5.opt(+0x14adf80)[0x5613bc764f80]
build/ARM_MESI_Three_Level_HTM/gem5.opt(+0xe5f8f7)[0x5613bc1168f7]
/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x6372)[0x7fae9c07bff2]
/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x7f8)[0x7fae9c075628]
/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x6f81)[0x7fae9c07cc01]
/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x7f8)[0x7fae9c075628]
/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x6f81)[0x7fae9c07cc01]
/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x7f8)[0x7fae9c075628]
/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x6f81)[0x7fae9c07cc01]
/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x7f8)[0x7fae9c075628]
/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCode+0x19)[0x7fae9c075b39]
/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x6e76)[0x7fae9c07caf6]
/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x7f8)[0x7fae9c075628]
/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x6f81)[0x7fae9c07cc01]
/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x7f8)[0x7fae9c075628]
/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCode+0x19)[0x7fae9c075b39]
/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyRun_StringFlags+0x76)[0x7fae9c04e846]
build/ARM_MESI_Three_Level_HTM/gem5.opt(_Z6m5MainiPPc+0x8b)[0x5613bc85275b]
build/ARM_MESI_Three_Level_HTM/gem5.opt(main+0x4c)[0x5613bbea522c]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0x7fae9b5160b3]
build/ARM_MESI_Three_Level_HTM/gem5.opt(_start+0x2e)[0x5613bbed639e]
--- END LIBC BACKTRACE ---
./run-this.sh: line 28: 7 Segmentation fault
 (core dumped) build/ARM_MESI_Three_Level_HTM/gem5.opt configs/example/fs.py 
--ruby --num-cpus=3 \  --cpu-type=TimingSimpleCPU --kernel=../system/vmlinux 
--machine-type=VExpress_GEM5_V1 \  
--dtb-file=./system/arm/dt/armv8_gem5_v1_1cpu.dtb 
--disk-image=linaro-minimal-aarch64.img \
 --bootloader=./system/arm/bootloader/arm64/boot_v2.arm64
___
gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to 
gem5-users-le...@gem5.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
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