Re: [m5-dev] Ruby FS - DMA Controller problem?

2011-03-15 Thread Korey Sewell 
Sorry for the confusion, I definitely "garbled up" some terminology.

I meant that the M5 ran with the atomic model to compare with the timing
Ruby model.

M5-atomic maybe runs in 10-15 mins and then Ruby 20-30 mins.

I am able to get the problem point in the Ruby simulation (bad DMA access)
in about 20 mins.

I able to get to that same problem point in the M5-atomic mode in about 10
mins so as to see what to compare against and what values are being
set/unset incorrectly.



On Tue, Mar 15, 2011 at 6:22 PM, Beckmann, Brad wrote:

> I'm confused.
>
> Korey, I thought this DMA problem only existed with Ruby?  If so, how were
> you able to reproduce it using atomic mode?  Ruby does not work with the
> atomic cpu model.
>
> Please clarify, thanks!
>
> Brad
>
> > -Original Message-
> > From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org]
> > On Behalf Of Korey Sewell
> > Sent: Tuesday, March 15, 2011 12:09 PM
> > To: M5 Developer List
> > Subject: Re: [m5-dev] Ruby FS - DMA Controller problem?
> >
> > Hi Brad/Malek,
> > I've been able to regenerate this error  in about 20mins now (instead of
> > hours) by running things in atomic mode. Not sure if that helps or not...
> >
> > On Tue, Mar 15, 2011 at 3:03 PM, Beckmann, Brad
> > wrote:
> >
> > > > How is that you are able to run the memtester in FS Mode?
> > > > I see the ruby_mem_tester.py in /configs/example/ but it seems that
> > > > it is only configured for SE Mode as far as Ruby is concerned?
> > >
> > > I don't run it in FS mode.  Since the DMA bug manifests only after
> > > hours of execution, I wanted to first verify that the DMA protocol
> > > support was solid using the mem tester.  Somewhat surprisingly, I
> > > found several bugs in MOESI_CMP_directory's support of DMA.  It turns
> > > out that the initial DMA support in that protocol wasn't very well
> > > thought out.  Now I fixed those bugs, but since the DMA problem also
> > > arises with the MOESI_hammer protocol, I'm confident that my patches
> > don't fix the real problem.
> > >
> > > Brad
> > >
> > > ___
> > > m5-dev mailing list
> > > m5-dev@m5sim.org
> > > http://m5sim.org/mailman/listinfo/m5-dev
> > >
> >
> >
> >
> > --
> > - Korey
> > ___
> > m5-dev mailing list
> > m5-dev@m5sim.org
> > http://m5sim.org/mailman/listinfo/m5-dev
>
>
> ___
> m5-dev mailing list
> m5-dev@m5sim.org
> http://m5sim.org/mailman/listinfo/m5-dev
>



-- 
- Korey
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

Re: [m5-dev] Ruby FS - DMA Controller problem?

2011-03-15 Thread Beckmann, Brad 
I'm confused.

Korey, I thought this DMA problem only existed with Ruby?  If so, how were you 
able to reproduce it using atomic mode?  Ruby does not work with the atomic cpu 
model.

Please clarify, thanks!

Brad

> -Original Message-
> From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org]
> On Behalf Of Korey Sewell
> Sent: Tuesday, March 15, 2011 12:09 PM
> To: M5 Developer List
> Subject: Re: [m5-dev] Ruby FS - DMA Controller problem?
> 
> Hi Brad/Malek,
> I've been able to regenerate this error  in about 20mins now (instead of
> hours) by running things in atomic mode. Not sure if that helps or not...
> 
> On Tue, Mar 15, 2011 at 3:03 PM, Beckmann, Brad
> wrote:
> 
> > > How is that you are able to run the memtester in FS Mode?
> > > I see the ruby_mem_tester.py in /configs/example/ but it seems that
> > > it is only configured for SE Mode as far as Ruby is concerned?
> >
> > I don't run it in FS mode.  Since the DMA bug manifests only after
> > hours of execution, I wanted to first verify that the DMA protocol
> > support was solid using the mem tester.  Somewhat surprisingly, I
> > found several bugs in MOESI_CMP_directory's support of DMA.  It turns
> > out that the initial DMA support in that protocol wasn't very well
> > thought out.  Now I fixed those bugs, but since the DMA problem also
> > arises with the MOESI_hammer protocol, I'm confident that my patches
> don't fix the real problem.
> >
> > Brad
> >
> > ___
> > m5-dev mailing list
> > m5-dev@m5sim.org
> > http://m5sim.org/mailman/listinfo/m5-dev
> >
> 
> 
> 
> --
> - Korey
> ___
> m5-dev mailing list
> m5-dev@m5sim.org
> http://m5sim.org/mailman/listinfo/m5-dev


___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

Re: [m5-dev] Cron /z/m5/regression/do-regression quick

2011-03-15 Thread Gabe Black 
The X86_FS regressions have failed the last couple nights. The first
time I attributed to it not catching my change to M5_PATH and something
flaky happening with nfs. That was even more of a stretch the second
time. My new theory is that scons didn't see that the files the
regression uses or that the environment had changed and was just
reporting the old result, not rerunning the test. I deleted the previous
run for X86_FS (just the build/X86_FS/tests/fast directory) and
hopefully we'll now see our first "passed"s for X86_FS.

Gabe

On 03/15/11 00:08, Cron Daemon wrote:
> * build/X86_FS/tests/fast/quick/10.linux-boot/x86/linux/pc-simple-atomic 
> FAILED!
> * build/X86_FS/tests/fast/quick/10.linux-boot/x86/linux/pc-simple-timing 
> FAILED!
> * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/inorder-timing 
> passed.
> * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/o3-timing passed.
> * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-atomic 
> passed.
> * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-timing 
> passed.
> * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby 
> passed.
> * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/o3-timing passed.
> * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-atomic 
> passed.
> * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-timing 
> passed.
> * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby 
> passed.
> * build/ALPHA_SE/tests/fast/quick/01.hello-2T-smt/alpha/linux/o3-timing 
> passed.
> * build/ALPHA_SE/tests/fast/quick/20.eio-short/alpha/eio/simple-timing 
> passed.
> * build/ALPHA_SE/tests/fast/quick/20.eio-short/alpha/eio/simple-atomic 
> passed.
> * build/ALPHA_SE/tests/fast/quick/30.eio-mp/alpha/eio/simple-atomic-mp 
> passed.
> * build/ALPHA_SE/tests/fast/quick/30.eio-mp/alpha/eio/simple-timing-mp 
> passed.
> * build/ALPHA_SE/tests/fast/quick/50.memtest/alpha/linux/memtest passed.
> * build/ALPHA_SE/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby 
> passed.
> * build/ALPHA_SE/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby 
> passed.
> * 
> build/ALPHA_SE_MOESI_hammer/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_hammer
>  passed.
> * 
> build/ALPHA_SE_MOESI_hammer/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_hammer
>  passed.
> * 
> build/ALPHA_SE_MOESI_hammer/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby-MOESI_hammer
>  passed.
> * 
> build/ALPHA_SE_MOESI_hammer/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_hammer
>  passed.
> * 
> build/ALPHA_SE_MESI_CMP_directory/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MESI_CMP_directory
>  passed.
> * 
> build/ALPHA_SE_MESI_CMP_directory/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby-MESI_CMP_directory
>  passed.
> * 
> build/ALPHA_SE_MESI_CMP_directory/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby-MESI_CMP_directory
>  passed.
> * 
> build/ALPHA_SE_MESI_CMP_directory/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MESI_CMP_directory
>  passed.
> * 
> build/ALPHA_SE_MOESI_CMP_directory/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_directory
>  passed.
> * 
> build/ALPHA_SE_MOESI_CMP_directory/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_directory
>  passed.
> * 
> build/ALPHA_SE_MOESI_CMP_directory/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby-MOESI_CMP_directory
>  passed.
> * 
> build/ALPHA_SE_MOESI_CMP_directory/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_directory
>  passed.
> * 
> build/ALPHA_SE_MOESI_CMP_token/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_token
>  passed.
> * 
> build/ALPHA_SE_MOESI_CMP_token/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_token
>  passed.
> * 
> build/ALPHA_SE_MOESI_CMP_token/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby-MOESI_CMP_token
>  passed.
> * 
> build/ALPHA_SE_MOESI_CMP_token/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_token
>  passed.
> * 
> build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-atomic
>  passed.
> * 
> build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-atomic-dual
>  passed.
> * 
> build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-timing
>  passed.
> * 
> build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-timing-dual
>  passed.
> * 
> build/ALPHA_FS/tests/fast/quick/80.netperf-stream/alpha/linux/twosys-tsunami-simple-atomic
>  passed.
> * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/inorder-timing 
> passed.
> * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/o3-timing passed.
> * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux

Re: [m5-dev] Ruby FS - DMA Controller problem?

2011-03-15 Thread Korey Sewell 
Hi Brad/Malek,
I've been able to regenerate this error  in about 20mins now (instead of
hours) by running things in atomic mode. Not sure if that helps or not...

On Tue, Mar 15, 2011 at 3:03 PM, Beckmann, Brad wrote:

> > How is that you are able to run the memtester in FS Mode?
> > I see the ruby_mem_tester.py in /configs/example/ but it seems that it is
> > only configured for SE Mode as far as Ruby is concerned?
>
> I don't run it in FS mode.  Since the DMA bug manifests only after hours of
> execution, I wanted to first verify that the DMA protocol support was solid
> using the mem tester.  Somewhat surprisingly, I found several bugs in
> MOESI_CMP_directory's support of DMA.  It turns out that the initial DMA
> support in that protocol wasn't very well thought out.  Now I fixed those
> bugs, but since the DMA problem also arises with the MOESI_hammer protocol,
> I'm confident that my patches don't fix the real problem.
>
> Brad
>
> ___
> m5-dev mailing list
> m5-dev@m5sim.org
> http://m5sim.org/mailman/listinfo/m5-dev
>



-- 
- Korey
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

Re: [m5-dev] Ruby FS - DMA Controller problem?

2011-03-15 Thread Beckmann, Brad 
> How is that you are able to run the memtester in FS Mode?
> I see the ruby_mem_tester.py in /configs/example/ but it seems that it is
> only configured for SE Mode as far as Ruby is concerned?

I don't run it in FS mode.  Since the DMA bug manifests only after hours of 
execution, I wanted to first verify that the DMA protocol support was solid 
using the mem tester.  Somewhat surprisingly, I found several bugs in 
MOESI_CMP_directory's support of DMA.  It turns out that the initial DMA 
support in that protocol wasn't very well thought out.  Now I fixed those bugs, 
but since the DMA problem also arises with the MOESI_hammer protocol, I'm 
confident that my patches don't fix the real problem.

Brad

___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

Re: [m5-dev] Review Request: isa: get rid of expandForMT function

2011-03-15 Thread Korey Sewell 


> On 2011-03-15 11:08:23, Gabe Black wrote:
> > src/arch/mips/isa.hh, line 58
> > 
> >
> > Do you really want these to be static? Then they can't be changed 
> > between different CPUs which have separate ISA state. I can see how you 
> > might be treating them as constants, but I'm not familiar enough with MIPS 
> > to know if that makes sense.

That's a good point. 

I suppose I could give the constructor for the MIPS ISA some default parameters 
that would just automatically set the variables.

something like "ISA(uint8_t num_threads = 1, uint8_t num_vpes = 1)" could work.


- Korey


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/578/#review960
---


On 2011-03-14 17:34:17, Korey Sewell wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/578/
> ---
> 
> (Updated 2011-03-14 17:34:17)
> 
> 
> Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and 
> Nathan Binkert.
> 
> 
> Summary
> ---
> 
> isa: get rid of expandForMT function
> MIPS is the only ISA that cares about having a piece of ISA state integrate
> multiple threads so add constants for MIPS and relieve the other ISAs from 
> having
> to define this. Also, InOrder was the only core that was actively calling
> this function
> * * *
> isa: get rid of corespecific type
> The CoreSpecific type was used as a proxy to pass in HW specific params to
> a MIPS CPU, but since MIPS FS hasnt been touched for awhile, it makes sense
> to not force every other ISA to use CoreSpecific as well use a special
> reset function to set it. That probably should go in a PowerOn reset fault
>  anyway.
> 
> 
> Diffs
> -
> 
>   src/arch/alpha/isa.hh 6c9b532da0a6 
>   src/arch/alpha/types.hh 6c9b532da0a6 
>   src/arch/arm/types.hh 6c9b532da0a6 
>   src/arch/mips/isa.hh 6c9b532da0a6 
>   src/arch/mips/isa.cc 6c9b532da0a6 
>   src/arch/power/types.hh 6c9b532da0a6 
>   src/arch/sparc/types.hh 6c9b532da0a6 
>   src/arch/x86/types.hh 6c9b532da0a6 
>   src/cpu/BaseCPU.py 6c9b532da0a6 
>   src/cpu/base.hh 6c9b532da0a6 
>   src/cpu/inorder/cpu.hh 6c9b532da0a6 
>   src/cpu/inorder/cpu.cc 6c9b532da0a6 
> 
> Diff: http://reviews.m5sim.org/r/578/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Korey
> 
>

___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

Re: [m5-dev] Review Request: This patch makes garnet use the info about active and inactive vnets during allocation and power estimations etc

2011-03-15 Thread Brad Beckmann 

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/585/#review963
---

Ship it!


- Brad


On 2011-03-15 01:25:16, Tushar Krishna wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/585/
> ---
> 
> (Updated 2011-03-15 01:25:16)
> 
> 
> Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, Nathan 
> Binkert, and Brad Beckmann.
> 
> 
> Summary
> ---
> 
> This patch makes garnet use the info about active and inactive vnets during 
> allocation and power estimations etc
> 
> 
> Diffs
> -
> 
>   src/mem/ruby/network/garnet/fixed-pipeline/GarnetNetwork_d.cc 6c9b532da0a6 
>   src/mem/ruby/network/garnet/fixed-pipeline/Router_d.hh 6c9b532da0a6 
>   src/mem/ruby/network/garnet/fixed-pipeline/SWallocator_d.cc 6c9b532da0a6 
>   src/mem/ruby/network/garnet/fixed-pipeline/VCallocator_d.cc 6c9b532da0a6 
>   src/mem/ruby/network/garnet/flexible-pipeline/GarnetNetwork.cc 6c9b532da0a6 
>   src/mem/ruby/network/garnet/flexible-pipeline/Router.hh 6c9b532da0a6 
>   src/mem/ruby/network/garnet/flexible-pipeline/Router.cc 6c9b532da0a6 
>   src/mem/ruby/network/orion/NetworkPower.cc 6c9b532da0a6 
> 
> Diff: http://reviews.m5sim.org/r/585/diff
> 
> 
> Testing
> ---
> 
> using Network_test
> 
> 
> Thanks,
> 
> Tushar
> 
>

___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

Re: [m5-dev] Review Request: fix garnet flexible pipeline

2011-03-15 Thread Brad Beckmann 

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/584/#review962
---

Ship it!


- Brad


On 2011-03-15 01:19:06, Tushar Krishna wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/584/
> ---
> 
> (Updated 2011-03-15 01:19:06)
> 
> 
> Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, Nathan 
> Binkert, and Brad Beckmann.
> 
> 
> Summary
> ---
> 
> Minor fixes to garnet flexible pipeline + some more stats.
> 
> 
> Diffs
> -
> 
>   src/mem/ruby/network/garnet/flexible-pipeline/GarnetNetwork.hh 6c9b532da0a6 
>   src/mem/ruby/network/garnet/flexible-pipeline/GarnetNetwork.cc 6c9b532da0a6 
>   src/mem/ruby/network/garnet/flexible-pipeline/NetworkInterface.cc 
> 6c9b532da0a6 
>   src/mem/ruby/network/garnet/flexible-pipeline/Router.cc 6c9b532da0a6 
>   src/mem/ruby/network/garnet/flexible-pipeline/flit.hh 6c9b532da0a6 
>   src/mem/ruby/network/garnet/flexible-pipeline/flit.cc 6c9b532da0a6 
> 
> Diff: http://reviews.m5sim.org/r/584/diff
> 
> 
> Testing
> ---
> 
> using Network_test
> 
> 
> Thanks,
> 
> Tushar
> 
>

___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

Re: [m5-dev] Review Request: Network Tester Patch

2011-03-15 Thread Brad Beckmann 

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/561/#review961
---


Hi Tushar,

This patch basically looks done to me.  I just have a few minor comments below. 
 It seems that there are a few parameters that aren't used and should be 
removed.  Also I think you should add a better explanation of the expected 
values for the injection rate. 



configs/example/ruby_network_test.py


Why multiply by 1000?  What is the expected range of injection rate?



src/cpu/testers/networktest/NetworkTest.py


Is this parameter used?   If so, what does address to trace mean?



src/cpu/testers/networktest/NetworkTest.py


I think you can remove the functional port now, correct?



src/cpu/testers/networktest/networktest.cc


Again, I think you can remove the functional port.


- Brad


On 2011-03-15 01:14:34, Tushar Krishna wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/561/
> ---
> 
> (Updated 2011-03-15 01:14:34)
> 
> 
> Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, Nathan 
> Binkert, and Brad Beckmann.
> 
> 
> Summary
> ---
> 
> This patch adds the network tester for simple and garnet networks.
> The tester code is in testers/networktest.
> The tester can be invoked by configs/example/ruby_network_test.py.
> A dummy coherence protocol called Network_test is also addded for 
> network-only simulations and testing. The protocol takes in messages from the 
> tester and just pushes them into the network in the appropriate vnet, without 
> storing any state.
> 
> 
> Diffs
> -
> 
>   build_opts/ALPHA_SE_Network_test PRE-CREATION 
>   configs/example/ruby_network_test.py PRE-CREATION 
>   configs/ruby/Network_test.py PRE-CREATION 
>   src/cpu/testers/networktest/NetworkTest.py PRE-CREATION 
>   src/cpu/testers/networktest/SConscript PRE-CREATION 
>   src/cpu/testers/networktest/networktest.hh PRE-CREATION 
>   src/cpu/testers/networktest/networktest.cc PRE-CREATION 
>   src/mem/protocol/Network_test-cache.sm PRE-CREATION 
>   src/mem/protocol/Network_test-dir.sm PRE-CREATION 
>   src/mem/protocol/Network_test-msg.sm PRE-CREATION 
>   src/mem/protocol/Network_test.slicc PRE-CREATION 
>   src/mem/protocol/SConsopts 6c9b532da0a6 
>   src/mem/ruby/network/garnet/BaseGarnetNetwork.hh 6c9b532da0a6 
>   src/mem/ruby/network/garnet/BaseGarnetNetwork.cc 6c9b532da0a6 
>   src/mem/ruby/network/garnet/BaseGarnetNetwork.py 6c9b532da0a6 
>   src/mem/ruby/network/garnet/fixed-pipeline/GarnetNetwork_d.cc 6c9b532da0a6 
>   src/mem/ruby/network/garnet/fixed-pipeline/NetworkInterface_d.cc 
> 6c9b532da0a6 
>   src/mem/ruby/network/garnet/flexible-pipeline/NetworkInterface.cc 
> 6c9b532da0a6 
>   src/mem/ruby/system/Sequencer.hh 6c9b532da0a6 
>   src/mem/ruby/system/Sequencer.cc 6c9b532da0a6 
>   src/mem/ruby/system/Sequencer.py 6c9b532da0a6 
> 
> Diff: http://reviews.m5sim.org/r/561/diff
> 
> 
> Testing
> ---
> 
> Testing done with garnet and simple networks. I will update config 
> assumptions etc on the wiki.
> 
> 
> Thanks,
> 
> Tushar
> 
>

___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

Re: [m5-dev] Review Request: isa: get rid of expandForMT function

2011-03-15 Thread Gabe Black 

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/578/#review960
---


I think this is a great change. There are only a couple small things to look 
at, and then of course making sure the regressions still work. I expect they 
will, but this touches a lot of areas so it's best to be sure.


src/arch/mips/isa.hh


Do you really want these to be static? Then they can't be changed between 
different CPUs which have separate ISA state. I can see how you might be 
treating them as constants, but I'm not familiar enough with MIPS to know if 
that makes sense.



src/arch/mips/isa.cc


This should be a panic, not an assert which will always be triggered.


- Gabe


On 2011-03-14 17:34:17, Korey Sewell wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/578/
> ---
> 
> (Updated 2011-03-14 17:34:17)
> 
> 
> Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and 
> Nathan Binkert.
> 
> 
> Summary
> ---
> 
> isa: get rid of expandForMT function
> MIPS is the only ISA that cares about having a piece of ISA state integrate
> multiple threads so add constants for MIPS and relieve the other ISAs from 
> having
> to define this. Also, InOrder was the only core that was actively calling
> this function
> * * *
> isa: get rid of corespecific type
> The CoreSpecific type was used as a proxy to pass in HW specific params to
> a MIPS CPU, but since MIPS FS hasnt been touched for awhile, it makes sense
> to not force every other ISA to use CoreSpecific as well use a special
> reset function to set it. That probably should go in a PowerOn reset fault
>  anyway.
> 
> 
> Diffs
> -
> 
>   src/arch/alpha/isa.hh 6c9b532da0a6 
>   src/arch/alpha/types.hh 6c9b532da0a6 
>   src/arch/arm/types.hh 6c9b532da0a6 
>   src/arch/mips/isa.hh 6c9b532da0a6 
>   src/arch/mips/isa.cc 6c9b532da0a6 
>   src/arch/power/types.hh 6c9b532da0a6 
>   src/arch/sparc/types.hh 6c9b532da0a6 
>   src/arch/x86/types.hh 6c9b532da0a6 
>   src/cpu/BaseCPU.py 6c9b532da0a6 
>   src/cpu/base.hh 6c9b532da0a6 
>   src/cpu/inorder/cpu.hh 6c9b532da0a6 
>   src/cpu/inorder/cpu.cc 6c9b532da0a6 
> 
> Diff: http://reviews.m5sim.org/r/578/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Korey
> 
>

___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

Re: [m5-dev] Ruby FS - DMA Controller problem?

2011-03-15 Thread Korey Sewell 
>
> Also, how would the default block size be '0' without that problem
> changeset?

The M5Port is derived from SimpleTimingPort (mem/tport.hh) which was derived
from Port (mem/port.hh) which has a virtual deviceBlockSize function that
always set to 0.



> If it was 0, doesn't that mean it's not passing the data
> from the DMA transfer? It would have to be at least 1?
>
I'm not sure about this, but I hope to find soon. More than likely some
default value is getting set if it see '0' or something invalid (But thats
just a guess).


-- 
- Korey
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

Re: [m5-dev] Ruby FS - DMA Controller problem?

2011-03-15 Thread Malek Musleh 
Hi Brad,

How is that you are able to run the memtester in FS Mode?
I see the ruby_mem_tester.py in /configs/example/ but it seems that it
is only configured for SE Mode as far as Ruby is concerned?

Also, how would the default block size be '0' without that problem
changeset? If it was 0, doesn't that mean it's not passing the data
from the DMA transfer? It would have to be at least 1?

Malek

On Mon, Mar 14, 2011 at 5:32 PM, Beckmann, Brad  wrote:
> Hi Malek,
>
> Just to reiterate, I don't think my patches will fix the underlining problem. 
>  Instead, my patches just fix various corner cases in the protocols.  I 
> suspect these corner cases are never actually reached in real execution.
>
> The fact that your dma traces point out that the Ruby and Classic 
> configurations use different base addresses makes me think this might be a 
> problem with configuration and device registration.  We should investigate 
> further.
>
> Brad
>
>
>> -Original Message-
>> From: Malek Musleh [mailto:malek.mus...@gmail.com]
>> Sent: Monday, March 14, 2011 9:11 AM
>> To: M5 Developer List
>> Cc: Beckmann, Brad
>> Subject: Re: [m5-dev] Ruby FS - DMA Controller problem?
>>
>> Hi Korey/Brad,
>>
>> I commented out the following lines:
>>
>> In RubyPort.hh
>>
>>  unsigned deviceBlockSize() const;
>>
>> In RubyPort.cc
>>
>> unsigned
>> RubyPort::M5Port::deviceBlockSize() const {
>>     return (unsigned) RubySystem::getBlockSizeBytes(); }
>>
>> I also did a diff trace between M5 and Ruby using the IdeDisk traceflag as
>> indicated earlier on.
>>
>> In the Ruby Trace, it stalls at this
>>
>> 2398589225000: system.disk0: Write to disk at offset: 0x1 data 0
>> 239858940: system.disk0: Write to disk at offset: 0x2 data 0x10
>> 2398589575000: system.disk0: Write to disk at offset: 0x3 data 0
>> 2398589742000: system.disk0: Write to disk at offset: 0x4 data 0
>> 2398589909000: system.disk0: Write to disk at offset: 0x5 data 0
>> 2398590088000: system.disk0: Write to disk at offset: 0x6 data 0xe0
>> 2398596763500: system.disk0: Write to disk at offset: 0x7 data 0xc8
>> 2398597916500: system.disk0: PRD: baseAddr:0x87298000 (0x7298000)
>> byteCount:8192 (16) eot:0x8000 sector:0
>> 2398597916500: system.disk0: doDmaWrite, diskDelay: 100
>> totalDiskDelay: 116
>>
>> Waiting for the Interrupt to be Posted.
>>
>> However, a comparison between the M5 and Ruby traces suggest that they
>> differ on the following line:
>>
>> RubyTrace:
>>
>> 239858940: system.disk0: Write to disk at offset: 0x2 data 0x10
>> 2398589575000: system.disk0: Write to disk at offset: 0x3 data 0
>> 2398589742000: system.disk0: Write to disk at offset: 0x4 data 0
>> 2398589909000: system.disk0: Write to disk at offset: 0x5 data 0
>> 2398590088000: system.disk0: Write to disk at offset: 0x6 data 0xe0
>> 2398596763500: system.disk0: Write to disk at offset: 0x7 data 0xc8
>> 2398597916500: system.disk0: PRD: baseAddr:0x87298000 (0x7298000)
>> byteCount:8192 (16) eot:0x8000 sector:0
>> 2398597916500: system.disk0: doDmaWrite, diskDelay: 100
>> totalDiskDelay: 116
>>
>>
>> M5 Trace:
>>
>> 2237623634000: system.disk0: Write to disk at offset: 0x7 data 0xc8
>> 2237624206501: system.disk0: PRD: baseAddr:0x87392000 (0x7392000)
>> byteCount:8192
>>  (16) eot:0x8000 sector:0
>> 2237624206501: system.disk0: doDmaWrite, diskDelay: 100
>> totalDiskDelay: 116
>>
>> If you note that the PRD:baseAddr it tries to access is different, which I 
>> would
>> think should be the same right? There is no reason why it should be
>> different? The 0 or 1 block size, and the sequential retries are forcing the
>> DMA timer to time out the request, and thus fails in the dma inconsistent
>> state.
>>
>> I have attached both sets of traces in case it sheds anymore light on to the
>> cause of the problem.
>>
>> In any case, it might not matter too much now since Brad was able to
>> reproduce the problem and has a patch for it, but may be of use for future
>> M5 changes.
>>
>> Malek
>>
>> On Mon, Mar 14, 2011 at 11:54 AM, Beckmann, Brad
>>  wrote:
>> > Thanks Malek.  Very interesting.
>> >
>> > Yes, this 5 line changeset seems rather benign, but actually has huge
>> ramifications.  With this change, the RubyPort passes the correct block size 
>> to
>> the cpu/device models.  Without it, I believe the block size defaults to 0 or
>> 1...I can't remember which.  While that seems rather inconsequential, I
>> noticed when I made this change that the memtester behaved quite
>> differently.  In particular, it keeps issuing requests until sendTiming 
>> returns
>> false, instead of just one request/cpu at a time.  Therefore another patch in
>> this series added the retry mechanism to the RubyPort.  I'm still not sure
>> exactly what the problem is with ruby+dma, but I suspect that the dma
>> devices are behaving differently now that the RubyPort passes the correct
>> block size.
>> >
>> > I was able to spend a few hours on this over the weekend.  I am now able
>> to repro

[m5-dev] Review Request: This patch makes garnet use the info about active and inactive vnets during allocation and power estimations etc

2011-03-15 Thread Tushar Krishna 

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/585/
---

Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, Nathan 
Binkert, and Brad Beckmann.


Summary
---

This patch makes garnet use the info about active and inactive vnets during 
allocation and power estimations etc


Diffs
-

  src/mem/ruby/network/garnet/fixed-pipeline/GarnetNetwork_d.cc 6c9b532da0a6 
  src/mem/ruby/network/garnet/fixed-pipeline/Router_d.hh 6c9b532da0a6 
  src/mem/ruby/network/garnet/fixed-pipeline/SWallocator_d.cc 6c9b532da0a6 
  src/mem/ruby/network/garnet/fixed-pipeline/VCallocator_d.cc 6c9b532da0a6 
  src/mem/ruby/network/garnet/flexible-pipeline/GarnetNetwork.cc 6c9b532da0a6 
  src/mem/ruby/network/garnet/flexible-pipeline/Router.hh 6c9b532da0a6 
  src/mem/ruby/network/garnet/flexible-pipeline/Router.cc 6c9b532da0a6 
  src/mem/ruby/network/orion/NetworkPower.cc 6c9b532da0a6 

Diff: http://reviews.m5sim.org/r/585/diff


Testing
---

using Network_test


Thanks,

Tushar

___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

[m5-dev] Review Request: fix garnet flexible pipeline

2011-03-15 Thread Tushar Krishna 

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/584/
---

Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, Nathan 
Binkert, and Brad Beckmann.


Summary
---

Minor fixes to garnet flexible pipeline + some more stats.


Diffs
-

  src/mem/ruby/network/garnet/flexible-pipeline/GarnetNetwork.hh 6c9b532da0a6 
  src/mem/ruby/network/garnet/flexible-pipeline/GarnetNetwork.cc 6c9b532da0a6 
  src/mem/ruby/network/garnet/flexible-pipeline/NetworkInterface.cc 
6c9b532da0a6 
  src/mem/ruby/network/garnet/flexible-pipeline/Router.cc 6c9b532da0a6 
  src/mem/ruby/network/garnet/flexible-pipeline/flit.hh 6c9b532da0a6 
  src/mem/ruby/network/garnet/flexible-pipeline/flit.cc 6c9b532da0a6 

Diff: http://reviews.m5sim.org/r/584/diff


Testing
---

using Network_test


Thanks,

Tushar

___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

Re: [m5-dev] Review Request: Network Tester Patch

2011-03-15 Thread Tushar Krishna 

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/561/
---

(Updated 2011-03-15 01:14:34.080951)


Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, Nathan 
Binkert, and Brad Beckmann.


Changes
---

addressed Brad's comments.
Specifically: removed second physical memory from ruby_network_tester.py, and 
added comments in networktest.cc and Network_test-cache/dir.sm files


Summary
---

This patch adds the network tester for simple and garnet networks.
The tester code is in testers/networktest.
The tester can be invoked by configs/example/ruby_network_test.py.
A dummy coherence protocol called Network_test is also addded for network-only 
simulations and testing. The protocol takes in messages from the tester and 
just pushes them into the network in the appropriate vnet, without storing any 
state.


Diffs (updated)
-

  build_opts/ALPHA_SE_Network_test PRE-CREATION 
  configs/example/ruby_network_test.py PRE-CREATION 
  configs/ruby/Network_test.py PRE-CREATION 
  src/cpu/testers/networktest/NetworkTest.py PRE-CREATION 
  src/cpu/testers/networktest/SConscript PRE-CREATION 
  src/cpu/testers/networktest/networktest.hh PRE-CREATION 
  src/cpu/testers/networktest/networktest.cc PRE-CREATION 
  src/mem/protocol/Network_test-cache.sm PRE-CREATION 
  src/mem/protocol/Network_test-dir.sm PRE-CREATION 
  src/mem/protocol/Network_test-msg.sm PRE-CREATION 
  src/mem/protocol/Network_test.slicc PRE-CREATION 
  src/mem/protocol/SConsopts 6c9b532da0a6 
  src/mem/ruby/network/garnet/BaseGarnetNetwork.hh 6c9b532da0a6 
  src/mem/ruby/network/garnet/BaseGarnetNetwork.cc 6c9b532da0a6 
  src/mem/ruby/network/garnet/BaseGarnetNetwork.py 6c9b532da0a6 
  src/mem/ruby/network/garnet/fixed-pipeline/GarnetNetwork_d.cc 6c9b532da0a6 
  src/mem/ruby/network/garnet/fixed-pipeline/NetworkInterface_d.cc 6c9b532da0a6 
  src/mem/ruby/network/garnet/flexible-pipeline/NetworkInterface.cc 
6c9b532da0a6 
  src/mem/ruby/system/Sequencer.hh 6c9b532da0a6 
  src/mem/ruby/system/Sequencer.cc 6c9b532da0a6 
  src/mem/ruby/system/Sequencer.py 6c9b532da0a6 

Diff: http://reviews.m5sim.org/r/561/diff


Testing
---

Testing done with garnet and simple networks. I will update config assumptions 
etc on the wiki.


Thanks,

Tushar

___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

[m5-dev] Cron /z/m5/regression/do-regression quick

2011-03-15 Thread Cron Daemon 
* build/X86_FS/tests/fast/quick/10.linux-boot/x86/linux/pc-simple-atomic 
FAILED!
* build/X86_FS/tests/fast/quick/10.linux-boot/x86/linux/pc-simple-timing 
FAILED!
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/inorder-timing 
passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/o3-timing passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-atomic passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-timing passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby 
passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/o3-timing passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-atomic passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-timing passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby 
passed.
* build/ALPHA_SE/tests/fast/quick/01.hello-2T-smt/alpha/linux/o3-timing 
passed.
* build/ALPHA_SE/tests/fast/quick/20.eio-short/alpha/eio/simple-timing 
passed.
* build/ALPHA_SE/tests/fast/quick/20.eio-short/alpha/eio/simple-atomic 
passed.
* build/ALPHA_SE/tests/fast/quick/30.eio-mp/alpha/eio/simple-atomic-mp 
passed.
* build/ALPHA_SE/tests/fast/quick/30.eio-mp/alpha/eio/simple-timing-mp 
passed.
* build/ALPHA_SE/tests/fast/quick/50.memtest/alpha/linux/memtest passed.
* build/ALPHA_SE/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby 
passed.
* build/ALPHA_SE/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby 
passed.
* 
build/ALPHA_SE_MOESI_hammer/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_hammer
 passed.
* 
build/ALPHA_SE_MOESI_hammer/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_hammer
 passed.
* 
build/ALPHA_SE_MOESI_hammer/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby-MOESI_hammer
 passed.
* 
build/ALPHA_SE_MOESI_hammer/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_hammer
 passed.
* 
build/ALPHA_SE_MESI_CMP_directory/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MESI_CMP_directory
 passed.
* 
build/ALPHA_SE_MESI_CMP_directory/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby-MESI_CMP_directory
 passed.
* 
build/ALPHA_SE_MESI_CMP_directory/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby-MESI_CMP_directory
 passed.
* 
build/ALPHA_SE_MESI_CMP_directory/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MESI_CMP_directory
 passed.
* 
build/ALPHA_SE_MOESI_CMP_directory/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_directory
 passed.
* 
build/ALPHA_SE_MOESI_CMP_directory/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_directory
 passed.
* 
build/ALPHA_SE_MOESI_CMP_directory/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby-MOESI_CMP_directory
 passed.
* 
build/ALPHA_SE_MOESI_CMP_directory/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_directory
 passed.
* 
build/ALPHA_SE_MOESI_CMP_token/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_token
 passed.
* 
build/ALPHA_SE_MOESI_CMP_token/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_token
 passed.
* 
build/ALPHA_SE_MOESI_CMP_token/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby-MOESI_CMP_token
 passed.
* 
build/ALPHA_SE_MOESI_CMP_token/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_token
 passed.
* 
build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-atomic 
passed.
* 
build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-atomic-dual
 passed.
* 
build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-timing 
passed.
* 
build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-timing-dual
 passed.
* 
build/ALPHA_FS/tests/fast/quick/80.netperf-stream/alpha/linux/twosys-tsunami-simple-atomic
 passed.
* build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/inorder-timing passed.
* build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/o3-timing passed.
* build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-atomic passed.
* build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-timing passed.
* build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-timing-ruby 
passed.
* build/POWER_SE/tests/fast/quick/00.hello/power/linux/o3-timing passed.
* build/POWER_SE/tests/fast/quick/00.hello/power/linux/simple-atomic passed.
* build/SPARC_SE/tests/fast/quick/00.hello/sparc/linux/simple-atomic passed.
* build/SPARC_SE/tests/fast/quick/00.hello/sparc/linux/simple-timing passed.
* build/SPARC_SE/tests/fast/quick/00.hello/sparc/linux/simple-timing-ruby 
passed.
* build/SPARC_SE/tests/fast/quick/02.insttest/sparc/linux/o3-timing passed.
* build/SPARC_SE/tests/fast/quick/02.insttest/sparc/linux/simple-atomic 
passed.
* build/SPARC_SE/tests/