Hai Matheus,

Thanks a lot for the suggestions. I have changed the L2 size to 256kB and these 
are the results for the simulation with MESI Two level protocol. 

GEM5 execution command:

build/X86/gem5.fast configs/example/fs.py --cpu-clock=2.5GHz --caches --ruby 
--cpu-type=timing --num-cpus=4 --num-l2cache=4 --num-dirs=4 --l1i_size=32kB 
--l1d_size=32kB --l2_size=256kB --topology=Mesh --mesh-rows=2 
--garnet-network=fixed --ruby-clock=2.5GHz

Result:
CPU frequency          Ruby frequency             Success/Failure
 2.0 GHz                  2.0 GHz                    Success
 2.5 GHz                  2.0 GHz                     Fail
 2.5 GHz                  2.5 GHz                    Success


Kindly let me know is it possible to have different frequency values for Ruby 
and CPU. (For my work I need to integrate DVFS handler with X86 cpu, so the I 
need the Ruby and CPU frequencies to be different at some point). 

----- Original Message -----
From: "Matheus Alcântara Souza" <[email protected]>
To: "Karthi Duraisamy" <[email protected]>, "gem5 users mailing list" 
<[email protected]>
Sent: Wednesday, January 21, 2015 9:40:18 AM
Subject: Re: [gem5-users] New Gem5-stable version- deadlock error with Garnet 
Fixed pipeline X86 FS simulation

Hi Karthi,

Try to reduce the L2 size (256kB for example) and to remove the cpu-clock
parameter. Also, uses the MESI_Two_Level protocol (I guess it is the most
suitable protocol for ruby). Let we know if it works.

Best,
Matheus

2015-01-21 15:30 GMT-02:00 Duraisamy, Karthi via gem5-users <
[email protected]>:

> The garnet flexible pipeline also failed with four cores.
>
> ----- Original Message -----
> From: "Karthi via gem5-users Duraisamy" <[email protected]>
> To: [email protected]
> Sent: Wednesday, January 21, 2015 8:59:56 AM
> Subject: [gem5-users] New Gem5-stable version- deadlock error with Garnet
> Fixed pipeline X86 FS simulation
>
> The new Gem5 stable version is not supporting fixed pipeline garnet
> simulations. The simulation just fails after entering the event queue. I
> have tried all the Ruby protocols (MOESI hammer, MESI two level, MESI CMP
> directory), still the bug persisted in all protocols.  With flexible
> pipeline the simulation is working fine.  I have attached the command used
> for executing Gem5 and the result I got. Kindly let me know how to fix this.
>
> command line: build/X86/gem5.fast configs/example/fs.py --caches --ruby
> --cpu-clock=2.5GHz --cpu-type=timing --num-cpus=4 --num-l2cache=4
> --num-dirs=4 --l1i_size=32kB --l1d_size=32kB --l2_size=8MB --topology=Mesh
> --mesh-rows=2 --garnet-network=fixed
> warn: add_child('cls'): child 'credit_links0 credit_links1' already has
> parent
> warn: add_child('cls'): child 'credit_links0 credit_links1' already has
> parent
> warn: add_child('cls'): child 'credit_links0 credit_links1' already has
> parent
> warn: add_child('cls'): child 'credit_links0 credit_links1' already has
> parent
> warn: add_child('cls'): child 'credit_links0 credit_links1' already has
> parent
> warn: add_child('cls'): child 'credit_links0 credit_links1' already has
> parent
> warn: add_child('cls'): child 'credit_links0 credit_links1' already has
> parent
> warn: add_child('cls'): child 'credit_links0 credit_links1' already has
> parent
> warn: add_child('cls'): child 'credit_links0 credit_links1' already has
> parent
> warn: add_child('cls'): child 'credit_links0 credit_links1' already has
> parent
> warn: add_child('cls'): child 'credit_links0 credit_links1' already has
> parent
> warn: add_child('cls'): child 'credit_links0 credit_links1' already has
> parent
> warn: add_child('cls'): child 'credit_links0 credit_links1' already has
> parent
> warn: add_child('cls'): child 'credit_links0 credit_links1' already has
> parent
> warn: add_child('cls'): child 'credit_links0 credit_links1' already has
> parent
> warn: add_child('cls'): child 'credit_links0 credit_links1' already has
> parent
> warn: add_child('cls'): child 'credit_links0 credit_links1' already has
> parent
> Global frequency set at 1000000000000 ticks per second
> info: kernel located at:
> /net/g/kduraisa/pvt/own_library/gem5/system/binaries/vmlinux
> Listening for com_1 connection on port 3456
> warn: Reading current count from inactive timer.
> 0: system.remote_gdb.listener: listening for remote gdb on port 7000
> 0: system.remote_gdb.listener: listening for remote gdb on port 7001
> 0: system.remote_gdb.listener: listening for remote gdb on port 7002
> 0: system.remote_gdb.listener: listening for remote gdb on port 7003
> **** REAL SIMULATION ****
> info: Entering event queue @ 0.  Starting simulation...
> panic: Possible Deadlock detected. Aborting!
> version: 0 request.paddr: 0x[0x1fdf380, line 0x1fdf380]
> m_readRequestTable: 1 current time: 3400002000 issue_time: 3160606000
> difference: 239396000 threshold:200000000
>  @ tick 3400002000
> [wakeup:build/X86/mem/ruby/system/Sequencer.cc, line 102]
> Memory Usage: 993736 KBytes
> Program aborted at tick 3400002000
> Abort (core dumped)
>
> Karthi Duraisamy
> Research Scholar
> School of Electrical Engineering and Computer Science
> Washington State University
> _______________________________________________
> 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
>



-- 

Atenciosamente,
Matheus Alcântara Souza
_______________________________________________
gem5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

Reply via email to