[gem5-users] How can I Run Full system on Ubuntu18.04 and X86?

2021-10-05 Thread Jeongmin via gem5-users
Hi All,

I'm trying to use the Gem5 full system.
but It doesn't work.

These are my configurations
-kernel = vmlinux-4.19.83 (5.4.49 / 4.14.134)
-Ubuntu = ubuntu-18.04.6-live-server-amd64 (tried 16.04)
-gem5 = 21.1.0.2
-X86 architecture
-I will use an O3CPU and DRAMsim3.

I made an image by using qemu and I completed the booting system.
To make the image, I use this command "qemu-system -hda  -cdrom
 -m 8G -enable-kvm"
The image size for ubuntu18.04.6 is 8.6GB.

All files are in ~/gem5/fs

and I changed "M5_PATH" to "/home/user/gem5/fs" in Syspath.py line 34.

As far as I know, These are all configurations to use the gem5 full system.

So I ran gem5. but it does not work.

I attached all command and error messages below.

How can I run the gem5 full system?
Please let me know.
Thanks in advance.



**
-cmd = ./build/X86/gem5.opt configs/example/fs.py
--kernel=/home/user/gem5/fs/vmlinux-4.19.83
--disk-image=/home/user/gem5/fs/ubuntu.img
(--cpu-type=AtomicSimpleCPU --mem-type=DDR4_2400_8x8 --mem-size=1GB
--num-cpu=1 --caches --root-device=/dev/hda)

**

warn: iobus.slave is deprecated. `slave` is now called `cpu_side_ports`
warn: bridge.master is deprecated. `master` is now called `mem_side_port`
warn: membus.master is deprecated. `master` is now called `mem_side_ports`
warn: bridge.slave is deprecated. `slave` is now called `cpu_side_port`
warn: iobus.master is deprecated. `master` is now called `mem_side_ports`
warn: apicbridge.slave is deprecated. `slave` is now called `cpu_side_port`
warn: membus.slave is deprecated. `slave` is now called `cpu_side_ports`
warn: apicbridge.master is deprecated. `master` is now called
`mem_side_port`
warn: membus.slave is deprecated. `slave` is now called `cpu_side_ports`
warn: iobus.master is deprecated. `master` is now called `mem_side_ports`
warn: membus.slave is deprecated. `slave` is now called `cpu_side_ports`
warn: membus.slave is deprecated. `slave` is now called `cpu_side_ports`
warn: membus.slave is deprecated. `slave` is now called `cpu_side_ports`
warn: membus.slave is deprecated. `slave` is now called `cpu_side_ports`
warn: membus.slave is deprecated. `slave` is now called `cpu_side_ports`
warn: membus.master is deprecated. `master` is now called `mem_side_ports`
warn: membus.master is deprecated. `master` is now called `mem_side_ports`
warn: membus.slave is deprecated. `slave` is now called `cpu_side_ports`
Global frequency set at 1 ticks per second
warn: system.workload.acpi_description_table_pointer.rsdt adopting orphan
SimObject param 'entries'
warn: No dot file generated. Please install pydot to generate the dot file
and pdf.
build/X86/mem/mem_interface.cc:793: warn: DRAM device capacity (16384
Mbytes) does not match the address range assigned (1024 Mbytes)
build/X86/sim/kernel_workload.cc:46: info: kernel located at:
/home/msm/gem5/fs/vmlinux-4.19.83
  0: system.pc.south_bridge.cmos.rtc: Real-time clock set to Sun Jan  1
00:00:00 2012
system.pc.com_1.device: Listening for connections on port 3456
0: system.remote_gdb: listening for remote gdb on port 7000
build/X86/dev/intel_8254_timer.cc:125: warn: Reading current count from
inactive timer.
 REAL SIMULATION 
build/X86/sim/simulate.cc:107: info: Entering event queue @ 0.  Starting
simulation...
build/X86/arch/x86/cpuid.cc:181: warn: x86 cpuid family 0x:
unimplemented function 6
build/X86/arch/x86/cpuid.cc:181: warn: x86 cpuid family 0x:
unimplemented function 6
build/X86/arch/x86/cpuid.cc:181: warn: x86 cpuid family 0x:
unimplemented function 6
build/X86/arch/x86/generated/exec-ns.cc.inc:27: warn: instruction 'fninit'
unimplemented
build/X86/dev/x86/pc.cc:117: warn: Don't know what interrupt to clear for
console.
44655759500: system.pc.com_1.device: attach terminal 0
build/X86/arch/x86/generated/exec-ns.cc.inc:27: warn: instruction 'sgdt_Ms'
unimplemented
build/X86/arch/x86/cpuid.cc:181: warn: x86 cpuid family 0x:
unimplemented function 6
build/X86/arch/x86/cpuid.cc:181: warn: x86 cpuid family 0x:
unimplemented function 6
build/X86/arch/x86/cpuid.cc:181: warn: x86 cpuid family 0x:
unimplemented function 6
build/X86/arch/x86/cpuid.cc:185: warn: x86 cpuid: unknown family 0x4000
build/X86/dev/x86/pc.cc:130: warn: Tried to clear PCI interrupt 14
build/X86/dev/storage/ide_disk.cc:564: panic: Can't read from
system.pc.south_bridge.ide.disks0. Only 4294967295 of 512 read. errno=21
Memory Usage: 1521004 KBytes
Program aborted at tick 1749666522001
--- BEGIN LIBC BACKTRACE ---
./build/X86/gem5.opt(+0x1fb4cc)[0x557dd59344cc]
./build/X86/gem5.opt(+0x23101a)[0x557dd596a01a]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x12980)[0x7f4cc3698980]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0xc7)[0x7f4cc1c42fb7]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x141)[0x7f4cc1c44921]

[gem5-users] --machine-type=VExpress_EMM causing ports collision

2021-10-05 Thread Carlos Andres Lara Niño via gem5-users
Hello,
I'm trying to learn gem5 and have been following the guide to the point
where I can specify different characteristics of the system using the fs.py
file.

However, when I try the configuration

build/ARM/gem5.opt \
configs/example/fs.py \
--cpu-type=TimingSimpleCPU \
--num-cpus=2 \
--caches \
--l2cache \
--machine-type=VExpress_EMM \
--bootloader="$IMG_ROOT/binaries/boot_emm.arm64" \
--kernel="$IMG_ROOT/binaries/vmlinux.arm64" \
--disk-image="$IMG_ROOT/img/ubuntu-18.04-arm64-docker.img" \
--cpu-clock=\['1 GHz','700 MHz','500 MHz'\]


It produces the following error:
build/ARM/mem/xbar.cc:431: fatal: system.iobus has two ports responding
within range [0:0x4]:
system.realview.cf_ctrl.pio
system.realview.cf_ctrl.pio

I've tinkered with the options a bit and reached the conclusion that
setting "--machine-type=VExpress_EMM" invariably causes this issue.

I haven't modified my gem5 distribution and the $IMG_ROOT path is as
specified in the tutorial. What could be the problem?

Best,
___
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: CHI_config.py

2021-10-05 Thread Javed Osmany via gem5-users
Hello

>> If the answer to the above question is yes, then why even have that 
>> attribute for the class?

Looking in more detail, CHI_HNFController is derived from CHI_Cache_Controller 
class.
The CHI_Cache_Controller class is used to derive the CHI_L1Controller and 
CHI_L2Controller class objects. In these cases the number_of_snoop_TBEs 
attribute is used to handle the number of snoop requests the respective cache 
controller can receive.


Best regards
J.Osmany

From: Javed Osmany
Sent: 05 October 2021 16:33
To: gem5-users@gem5.org
Cc: Javed Osmany 
Subject: CHI_config.py

Hello

In CHI_config.py, for the class CHI_HNFController we have

class CHI_HNFController(CHI_Cache_controller):
  :
  :
# Some reasonable default TBE params
self.number_of_TBEs = 32
self.number_of_repl_TBEs = 32
self.number_of_snoop_TBEs = 1 # should not receive any snoop
self.unify_repl_TBEs = False
   :


The number_of_snoop_TBEs is set to 1 with the corresponding comment.
This seems to indicate that the number_of_snoop_TBEs can be left at 1 since the 
CHI_HNFController should not receive any snoop requests.
Is this because a RNF coherence request which gets a hit in the directory will 
generate a snoop request to one or more other RNFs which may be holding a copy 
of the cache line?
If the answer to the above question is yes, then why even have that attribute 
for the class?


Thanks in advance
J.Osmany
___
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] CHI_config.py

2021-10-05 Thread Javed Osmany via gem5-users
Hello

In CHI_config.py, for the class CHI_HNFController we have

class CHI_HNFController(CHI_Cache_controller):
  :
  :
# Some reasonable default TBE params
self.number_of_TBEs = 32
self.number_of_repl_TBEs = 32
self.number_of_snoop_TBEs = 1 # should not receive any snoop
self.unify_repl_TBEs = False
   :


The number_of_snoop_TBEs is set to 1 with the corresponding comment.
This seems to indicate that the number_of_snoop_TBEs can be left at 1 since the 
CHI_HNFController should not receive any snoop requests.
Is this because a RNF coherence request which gets a hit in the directory will 
generate a snoop request to one or more other RNFs which may be holding a copy 
of the cache line?
If the answer to the above question is yes, then why even have that attribute 
for the class?


Thanks in advance
J.Osmany
___
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: Porting a configuration file from gem5 v20 to gem5 v21

2021-10-05 Thread Ali Ghandour via gem5-users
In FS mode, full errror stack below:

Traceback (most recent call last):
  File "", line 1, in 
  File "build/ARM/python/m5/main.py", line 455, in main
  File "./RPIv4.py", line 535, in 
main()
  File "./RPIv4.py", line 512, in main
root.system = systemCreate(args)
  File "./RPIv4.py", line 297, in systemCreate
system = RPISystemCreate(ArmSystem, args, mode)
  File "./RPIv4.py", line 182, in RPISystemCreate
return RPISystem(args, mode)
  File "./RPIv4.py", line 127, in __init__
self.configMem(args)
  File "./RPIv4.py", line 158, in configMem
self.cpu_cluster.connectDirect(self.membus)
  File 
"/home/ali/Desktop/spirals/reproduce-spectre-gem5/gem5/./ARMv8A_Cortex_A72.py", 
line 325, in connectDirect
cpu.dtb.walker.port = bus.slave
  File "build/ARM/python/m5/SimObject.py", line 1416, in __getattr__
AttributeError: object 'ARM_A72_TLB_L1D' has no attribute 'walker'
  (C++ object is not yet constructed, so wrapped C++ methods are unavailable.)
___
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: Segmentation fault when restoring checkpoint in with DerivO3CPU

2021-10-05 Thread Eliot Moss via gem5-users

On 10/5/2021 8:01 AM, Đức Anh wrote:
> Hi Eliot,
>
> How could you restore the checkpoint with fs.py? What command option did you 
use? I read through the
> fs.py file so I believed m5.instatiate() is enough. I am using
> - gem5 version [DEVELOP-FOR-V21.2]
> - commit 6811158b28bd293487fb5e4bbbfb4bc2d5c259cb
> - GCC version 7.5.0 and 11.1.0 (I tried both)
> - Ubuntu 18.04

Here's the command I run.  My OS kernel is modified, but not in ways that
would matter.  My gem5 version 21.0, not 21.2.  My gcc is 10.3.0.  I believe
my fs.py is out-of-the-box.  You probably know this, but some of the arguments
on the command line are to gem5 and others are to fs.py.  It's important to
get them in the right place (before / after fs.py on the command line).

I believe it looks for the checkpoint directory inside the --path directory.

./build/X86/gem5.fast --stats-file=stats_gem5.txt.gz 
--outdir=/home/moss/Autoclean/work/scenarios/a01/default/m5out 
--path=/home/moss/Autoclean/work/scenarios/a01/default/m5out --quiet --listener-mode=on 
./configs/example/fs.py --cpu-type=DerivO3CPU --num-cpu=1 --cpu-clock=3GHz 
--script=/home/moss/Autoclean/work/scenarios/a01/default/m5out/do.rcs --caches --l2cache 
--l1i_size=32kB --l1d_size=64kB --l2_size=4MB --mem-type=LPDDR5_6400_1x16_BG_BL32 --mem-size=512MB 
--cacheline_size=64 --kernel=/home/moss/Autoclean/work/linux_kernel/vmlinux-5.2.3 
--disk-image=/home/moss/Autoclean/work/gem5-images/ubuntu-18.04/ubuntu-18.04-base.img 
--disk-image=/home/moss/Autoclean/AUTOC/../work/gem5-images/extra.img.2430.tmp 
--checkpoint-restore=1 --restore-with-cpu=DerivO3CP


Best wishes - EM
___
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] Porting a configuration file from gem5 v20 to gem5 v21

2021-10-05 Thread Ali Ghandour via gem5-users
I have a config file that is working properly using gem5 v20.

I spent a lot of time trying to run it using the latest version of gem5.

In SE mode, it gives a segmentation fault.

I tried to debug it using GDB and GEF.
The fault is triggered in


#1  0x55dc2969 in gem5::o3::CPU::trap (this=0x5b7ca000,
fault=std::shared_ptr (use count 2, weak count 0) = {...},
tid=0x0, inst=...) at build/ARM/cpu/o3/cpu.cc:905
905fault->invoke(threadContexts[tid], inst);


In FS mode, it gives the following error:
  File "build/ARM/python/m5/SimObject.py", line 1416, in __getattr__
AttributeError: object 'ARM_A72_Cluster' has no attribute 'l2'
  (C++ object is not yet constructed, so wrapped C++ methods are
unavailable.)





*My question:Is there a systematic approach thatI can follow to get the
config file working using the latest version of gem5?*
___
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: Segmentation fault when restoring checkpoint in with DerivO3CPU

2021-10-05 Thread Đức Anh via gem5-users
Hi Eliot,

How could you restore the checkpoint with fs.py? What command option did
you use? I read through the fs.py file so I
believed m5.instatiate() is enough. I am using
- gem5 version [DEVELOP-FOR-V21.2]
- commit 6811158b28bd293487fb5e4bbbfb4bc2d5c259cb
- GCC version 7.5.0 and 11.1.0 (I tried both)
- Ubuntu 18.04

Best regards,
Duc Anh

On Tue, 5 Oct 2021 at 03:43, Eliot Moss  wrote:

> On 10/4/2021 4:46 PM, Đức Anh via gem5-users wrote:
> > Dear all,
> >
> > I am trying to use the checkpoint feature to skip the long and tired
> Linux booting part of the ARM
> > FS simulation. However, Gem5 throws the Segmentation fault when I try to
> restore the checkpoint. It
> > works fine with AtomicSimpleCPU, though.
> >
> > Here is the script I used to take the checkpoint
> > - run ./m5 checkpoint through the connected terminal
> > - in the python script, run m5.checkpoint("m5out/cpt.%d") and
> m5.simulate() again.
> >
> > Then I restore the checkpoint by:
> > m5.instantiate()
> > m5.simulate()
> >
> > There is no CPU switching. I used DeriveO3CPU
> >
> > I also tried the fs.py script with --checkpoint-restore option but the
> problem persists. Here is the
> > error log:
> >
> > --- BEGIN LIBC BACKTRACE ---
> > build/ARM/gem5.opt(_ZN4gem515print_backtraceEv+0x2c)[0x55a2b680abec]
> > build/ARM/gem5.opt(+0x1c346ef)[0x55a2b68266ef]
> > /lib/x86_64-linux-gnu/libpthread.so.0(+0x12980)[0x7fa8ee493980]
> > --- END LIBC BACKTRACE ---
> > Segmentation fault (core dumped)
> >
> > I read in one of the older emails that fs.py is outdated. Perhaps
> dealing with checkpoint and
> > DerivO3CPU need another way?
>
> See recent posts - folks are on the trail of a bug in either
> the C++ code, C/C++ libraries, or C++ compiler / tool chain.
> If it's the same bug then it has to do with the simulator's
> memory management somehow (or a pointer gets zapped) - the
> result is a bad free.  This may NOT be the same issue.  The
> backtrace I get from gem5.opt indicates a bad free with
> tcmalloc reporting it.
>
> fs.py has worked for me, maybe with some customizations.
> I think that the wording about it is trying to suggest that
> it's perhaps a bit rigid or limiting for things a lot of people
> may want to do ...
>
> Regards - Eliot Moss
>
___
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