Re: [m5-dev] Review Request: my initial implementation of cache flushing

[Brad Beckmann]

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


Hi Somayeh,

This looks great.  I just have a couple comments below.  Once you address them, 
you can consider it done from my perspective.


src/cpu/testers/rubytest/Check.cc


Instead of hard coding the flush requests with a true/false statement, we 
should have a flag passed in from ruby_random_test.py.  Also in 
ruby_random_test.py you can test which protocol was compiled with the binary 
and ensure that flush requests are only enabled for the MOESI_hammer protocol.



src/mem/protocol/RubySlicc_Types.sm


I don't think these functions exist anymore, correct?  I think you can 
remove these declarations then.


- Brad


On 2011-03-22 19:33:58, Somayeh Sardashti wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/552/
> ---
> 
> (Updated 2011-03-22 19:33:58)
> 
> 
> Review request for Default and Brad Beckmann.
> 
> 
> Summary
> ---
> 
> my initial implementation of cache flushing
> 
> 
> Diffs
> -
> 
>   src/cpu/testers/rubytest/Check.hh baf4b5f6782e 
>   src/cpu/testers/rubytest/Check.cc baf4b5f6782e 
>   src/mem/packet.hh baf4b5f6782e 
>   src/mem/packet.cc baf4b5f6782e 
>   src/mem/protocol/MOESI_hammer-cache.sm baf4b5f6782e 
>   src/mem/protocol/MOESI_hammer-dir.sm baf4b5f6782e 
>   src/mem/protocol/MOESI_hammer-msg.sm baf4b5f6782e 
>   src/mem/protocol/RubySlicc_Exports.sm baf4b5f6782e 
>   src/mem/protocol/RubySlicc_Types.sm baf4b5f6782e 
>   src/mem/ruby/slicc_interface/RubyRequest.hh baf4b5f6782e 
>   src/mem/ruby/slicc_interface/RubyRequest.cc baf4b5f6782e 
>   src/mem/ruby/system/DMASequencer.cc baf4b5f6782e 
>   src/mem/ruby/system/RubyPort.cc baf4b5f6782e 
>   src/mem/ruby/system/Sequencer.cc baf4b5f6782e 
> 
> Diff: http://reviews.m5sim.org/r/552/diff
> 
> 
> Testing
> ---
> 
> This implementation has passed 10,000,000 ruby test cases, and the 
> MOESI_hammer regression tests.
> 
> 
> Thanks,
> 
> Somayeh
> 
>

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

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

[Beckmann, Brad]

Nevermind those.  I had several incoming and outgoing emails from the weekend 
that finally got through our system.

Brad

  

> -Original Message-
> From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] On
> Behalf Of Nilay
> Sent: Tuesday, March 22, 2011 8:07 PM
> To: M5 Developer List
> Subject: Re: [m5-dev] Ruby FS - DMA Controller problem?
> 
> On Sat, March 19, 2011 6:01 pm, Beckmann, Brad wrote:
> > Korey, if you're deadlock is with running the MOESI_CMP_directory
> > protocol, I'm not surprised.  DMA support is pretty much broken in
> that
> > protocol.  I have that fixed and I also fixed the underlining DMA
> problem.
> >  I'll be pushing the fixes momentarily.
> >
> > Korey and Malek, please pull these changes and confirm they fix your
> > problem.
> >
> > Brad
> >
> >
> 
> Brad, how come the mails you sent on Saturday are being received now?
> 
> 
> --
> Nilay
> 
> ___
> 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] changeset in m5: This patch fixes a build error in networktest.c...

[Tushar Krishna]

Ah sorry Nate didn't know the commit convention. Will follow it in 
future checkins.


Is this link available from the m5sim wiki somewhere?
I tried searching in http://www.m5sim.org/wiki/index.php/Development and 
in http://www.m5sim.org/wiki/index.php/NewDoc#Development for the 
checkin conventions, but couldn't find them there.


Thanks,
Tushar


On 3/23/2011 12:38 PM, nathan binkert wrote:

description:
This patch fixes a build error in networktest.cc that occurs with gcc4.2

Tushar,

The above description doesn't follow our convention for commit messages.
Please read http://www.m5sim.org/wiki/index.php/Commit_Access
Specifically, the part about commit messages.

Also, saying "This patch..." doesn't add much.  Try to be concise in
that first line and give as much information as possible.

   Nate

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

Re: [m5-dev] changeset in m5: This patch fixes a build error in networktest.c...

[nathan binkert]

> description:
>        This patch fixes a build error in networktest.cc that occurs with 
> gcc4.2

Tushar,

The above description doesn't follow our convention for commit messages.
Please read http://www.m5sim.org/wiki/index.php/Commit_Access
Specifically, the part about commit messages.

Also, saying "This patch..." doesn't add much.  Try to be concise in
that first line and give as much information as possible.

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

Re: [m5-dev] networktest.cc error

[Tushar Krishna]

Thanks guys. Yeah I was using gcc4.3 which does not give this error, 
while gcc4.2 does.

I just checked in a patch to solve this.

Thanks,
Tushar


On 3/23/2011 10:56 AM, Nilay wrote:

On Tue, March 22, 2011 9:45 pm, Tushar Krishna wrote:

Hi all,
I didn't (and still don't) see any errors in networktest.cc when I built
m5 on my own computer for both SE and FS modes before checking in the
patch.
Could it be a gcc version issue?

The error which the regression tester points to is

build/ARM_FS/cpu/testers/networktest/networktest.cc:194: error: call
of overloaded 'pow(int, int&)' is ambiguous

The line which is giving the error is:
int injRange = pow(10, precision);

precision is an input parameter.

I just want to raise 10 to an input integer value. Is there any other
way I should use to do this?

What is the regression test that I should run to reproduce the errors
and warnings?

Thanks,
Tushar


Tushar, try compiling with GCC 4.2, that's the version on zizzer.

--
Nilay

___
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

[m5-dev] changeset in m5: This patch fixes a build error in networktest.c...

[Tushar Krishna]

changeset ec1eecca2f8f in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=ec1eecca2f8f
description:
This patch fixes a build error in networktest.cc that occurs with gcc4.2

diffstat:

 src/cpu/testers/networktest/networktest.cc |  6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diffs (23 lines):

diff -r e21f6e70169e -r ec1eecca2f8f src/cpu/testers/networktest/networktest.cc
--- a/src/cpu/testers/networktest/networktest.ccTue Mar 22 06:41:54 
2011 -0500
+++ b/src/cpu/testers/networktest/networktest.ccTue Mar 22 23:38:09 
2011 -0400
@@ -165,7 +165,7 @@
 
 assert(pkt->isResponse());
 noResponseCycles = 0;
-delete pkt->req;
+delete req;
 delete pkt;
 }
 
@@ -191,8 +191,8 @@
 // - generate a random number between 0 and 10^precision
 // - send pkt if this number is < injRate*(10^precision)
 bool send_this_cycle;
-int injRange = pow(10, precision);
-unsigned trySending = random() % injRange;
+double injRange = pow((double) 10, (double) precision);
+unsigned trySending = random() % (int) injRange;
 if (trySending < injRate*injRange)
 send_this_cycle = true;
 else
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

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

[Nilay]

On Sat, March 19, 2011 6:01 pm, Beckmann, Brad wrote:
> Korey, if you're deadlock is with running the MOESI_CMP_directory
> protocol, I'm not surprised.  DMA support is pretty much broken in that
> protocol.  I have that fixed and I also fixed the underlining DMA problem.
>  I'll be pushing the fixes momentarily.
>
> Korey and Malek, please pull these changes and confirm they fix your
> problem.
>
> Brad
>
>

Brad, how come the mails you sent on Saturday are being received now?


--
Nilay

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

Re: [m5-dev] Review Request: Ruby: Convert AccessModeType to RubyAccessMode

[Nilay]

On Sat, March 19, 2011 3:57 pm, Beckmann, Brad wrote:
> Nevermind, I understand the reason now.  This looks good to me.
>
> Thanks,
>
> Brad
>
>> -Original Message-
>> From: Beckmann, Brad
>> Sent: Saturday, March 19, 2011 1:50 PM
>> To: 'M5 Developer List'
>> Subject: RE: [m5-dev] Review Request: Ruby: Convert AccessModeType to
>> RubyAccessMode
>>
>> Hi Nilay,
>>
>> Why do you want to change the name?  Both names seem equivalent to me.
>>
>> Brad
>>
>>

Brad, I had to make the decision in favor of one of the two names. I
decided not to choose AccessModeType because Mode and Type have almost the
same meaning.


--
Nilay

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

Re: [m5-dev] networktest.cc error

[Nilay]

On Tue, March 22, 2011 9:45 pm, Tushar Krishna wrote:
> Hi all,
> I didn't (and still don't) see any errors in networktest.cc when I built
> m5 on my own computer for both SE and FS modes before checking in the
> patch.
> Could it be a gcc version issue?
>
> The error which the regression tester points to is
>
> build/ARM_FS/cpu/testers/networktest/networktest.cc:194: error: call
> of overloaded 'pow(int, int&)' is ambiguous
>
> The line which is giving the error is:
> int injRange = pow(10, precision);
>
> precision is an input parameter.
>
> I just want to raise 10 to an input integer value. Is there any other
> way I should use to do this?
>
> What is the regression test that I should run to reproduce the errors
> and warnings?
>
> Thanks,
> Tushar
>
Tushar, try compiling with GCC 4.2, that's the version on zizzer.

--
Nilay

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

Re: [m5-dev] networktest.cc error

[Gabe Black]

It could be a gcc version issue (it wouldn't be the first time). pow
expects its first argument to be a floating point value, and it's not
clear which one you want when the first argument is actually an int. If
you cast it to particular type of float explicitly, then gcc should be
happy. I suggest a double to avoid rounding issues.

http://www.cplusplus.com/reference/clibrary/cmath/pow/

Gabe

On 03/22/11 22:45, Tushar Krishna wrote:
> Hi all,
> I didn't (and still don't) see any errors in networktest.cc when I
> built m5 on my own computer for both SE and FS modes before checking
> in the patch.
> Could it be a gcc version issue?
>
> The error which the regression tester points to is
>
> build/ARM_FS/cpu/testers/networktest/networktest.cc:194: error: call
> of overloaded 'pow(int, int&)' is ambiguous
>
> The line which is giving the error is:
> int injRange = pow(10, precision);
>
> precision is an input parameter.
>
> I just want to raise 10 to an input integer value. Is there any other
> way I should use to do this?
>
> What is the regression test that I should run to reproduce the errors
> and warnings?
>
> Thanks,
> Tushar
>
>
> On 3/23/2011 9:49 AM, m5-dev-requ...@m5sim.org wrote:
>> Send m5-dev mailing list submissions to
>> m5-dev@m5sim.org
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>> http://m5sim.org/mailman/listinfo/m5-dev
>> or, via email, send a message with subject or body 'help' to
>> m5-dev-requ...@m5sim.org
>>
>> You can reach the person managing the list at
>> m5-dev-ow...@m5sim.org
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of m5-dev digest..."
>>
>>
>> Today's Topics:
>>
>> 1. Re: Cron/z/m5/regression/do-regression   
>> quick
>>(Gabriel Michael Black)
>> 2. Re: Cron  /z/m5/regression/do-regression quick
>>(Nilay Vaish)
>> 3. Re: Cron  /z/m5/regression/do-regressionquick
>>(nathan binkert)
>> 4. Re: Cron  /z/m5/regression/do-regression quick
>>(Nilay Vaish)
>> 5. Re: Cron  /z/m5/regression/do-regression quick
>>(Gabe Black)
>> 6. Re: Cron  /z/m5/regression/do-regression quick
>>(Beckmann, Brad)
>> 7. Ruby random tester failing with MESI_CMP_directory?
>>(Arkaprava Basu)
>> 8. Re: Ruby random tester failing with MESI_CMP_directory? (Nilay)
>> 9. Re: Ruby random tester failing with MESI_CMP_directory? (Lisa
>> Hsu)
>>
>>
>> --
>>
>> Message: 1
>> Date: Tue, 22 Mar 2011 14:47:42 -0400
>> From: Gabriel Michael Black
>> To: m5-dev@m5sim.org
>> Subject: Re: [m5-dev] Cron
>> /z/m5/regression/do-regressionquick
>> Message-ID:<20110322144742.201251r4bqtec...@mail.eecs.umich.edu>
>> Content-Type: text/plain;charset=ISO-8859-1;DelSp="Yes";
>> format="flowed"
>>
>> The two issues below are copied from ARM_FS, but other targets had the
>> same problems.
>>
>> These errors are making the build fail.
>>
>> build/ARM_FS/cpu/testers/networktest/networktest.cc: In member
>> function 'void NetworkTest::completeRequest(Packet*)':
>> build/ARM_FS/cpu/testers/networktest/networktest.cc:160: warning:
>> unused variable 'req'
>> build/ARM_FS/cpu/testers/networktest/networktest.cc: In member
>> function 'void NetworkTest::tick()':
>> build/ARM_FS/cpu/testers/networktest/networktest.cc:194: error: call
>> of overloaded 'pow(int, int&)' is ambiguous
>>
>>
>> These warnings should probably be cleaned up too, although I don't
>> know how long they've been there or how hard that would be.
>>
>> build/ARM_FS/mem/ruby/system/Sequencer.cc: In member function 'void
>> Sequencer::issueRequest(const RubyRequest&)':
>> build/ARM_FS/mem/ruby/system/Sequencer.cc:616: warning: 'ctype' may be
>> used uninitialized in this function
>> build/ARM_FS/mem/ruby/system/Sequencer.cc:653: warning: 'amtype' may
>> be used uninitialized in this function
>>
>> Quoting Cron Daemon:
>>
>>> scons: *** [build/ALPHA_SE/cpu/testers/networktest/networktest.fo]
>>> Error 1
>>> scons: ***
>>> [build/ALPHA_SE_MOESI_hammer/cpu/testers/networktest/networktest.fo]
>>> Error 1
>>> scons: ***
>>> [build/ALPHA_SE_MESI_CMP_directory/cpu/testers/networktest/networktest.fo]
>>>
>>> Error 1
>>> scons: ***
>>> [build/ALPHA_SE_MOESI_CMP_directory/cpu/testers/networktest/networktest.fo]
>>>
>>> Error 1
>>> scons: ***
>>> [build/ALPHA_SE_MOESI_CMP_token/cpu/testers/networktest/networktest.fo]
>>> Error 1
>>> scons: *** [build/ALPHA_FS/cpu/testers/networktest/networktest.fo]
>>> Error 1
>>> scons: *** [build/MIPS_SE/cpu/testers/networktest/networktest.fo]
>>> Error 1
>>> scons: *** [build/POWER_SE/cpu/testers/networktest/networktest.fo]
>>> Error 1
>>> scons: *** [build/SPARC_SE/cpu/testers/networktest/networktest.fo]
>>> Error 1
>>> scons: *** [build/X86_SE/cpu/testers/networktest/networktest.fo]
>>> Error 1
>>> scons: *** [build/X86_FS/cpu/testers/networktest/networktest.fo]
>>> Error 1
>

[m5-dev] networktest.cc error

[Tushar Krishna]

Hi all,
I didn't (and still don't) see any errors in networktest.cc when I built 
m5 on my own computer for both SE and FS modes before checking in the 
patch.

Could it be a gcc version issue?

The error which the regression tester points to is

build/ARM_FS/cpu/testers/networktest/networktest.cc:194: error: call
of overloaded 'pow(int, int&)' is ambiguous

The line which is giving the error is:
int injRange = pow(10, precision);

precision is an input parameter.

I just want to raise 10 to an input integer value. Is there any other 
way I should use to do this?


What is the regression test that I should run to reproduce the errors 
and warnings?


Thanks,
Tushar


On 3/23/2011 9:49 AM, m5-dev-requ...@m5sim.org wrote:

Send m5-dev mailing list submissions to
m5-dev@m5sim.org

To subscribe or unsubscribe via the World Wide Web, visit
http://m5sim.org/mailman/listinfo/m5-dev
or, via email, send a message with subject or body 'help' to
m5-dev-requ...@m5sim.org

You can reach the person managing the list at
m5-dev-ow...@m5sim.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of m5-dev digest..."


Today's Topics:

1. Re: Cron/z/m5/regression/do-regression  quick
   (Gabriel Michael Black)
2. Re: Cron  /z/m5/regression/do-regression quick
   (Nilay Vaish)
3. Re: Cron  /z/m5/regression/do-regressionquick
   (nathan binkert)
4. Re: Cron  /z/m5/regression/do-regression quick
   (Nilay Vaish)
5. Re: Cron  /z/m5/regression/do-regression quick
   (Gabe Black)
6. Re: Cron  /z/m5/regression/do-regression quick
   (Beckmann, Brad)
7. Ruby random tester failing with MESI_CMP_directory?
   (Arkaprava Basu)
8. Re: Ruby random tester failing with MESI_CMP_directory? (Nilay)
9. Re: Ruby random tester failing with MESI_CMP_directory? (Lisa Hsu)


--

Message: 1
Date: Tue, 22 Mar 2011 14:47:42 -0400
From: Gabriel Michael Black
To: m5-dev@m5sim.org
Subject: Re: [m5-dev] Cron
/z/m5/regression/do-regression  quick
Message-ID:<20110322144742.201251r4bqtec...@mail.eecs.umich.edu>
Content-Type: text/plain;   charset=ISO-8859-1; DelSp="Yes";
format="flowed"

The two issues below are copied from ARM_FS, but other targets had the
same problems.

These errors are making the build fail.

build/ARM_FS/cpu/testers/networktest/networktest.cc: In member
function 'void NetworkTest::completeRequest(Packet*)':
build/ARM_FS/cpu/testers/networktest/networktest.cc:160: warning:
unused variable 'req'
build/ARM_FS/cpu/testers/networktest/networktest.cc: In member
function 'void NetworkTest::tick()':
build/ARM_FS/cpu/testers/networktest/networktest.cc:194: error: call
of overloaded 'pow(int, int&)' is ambiguous


These warnings should probably be cleaned up too, although I don't
know how long they've been there or how hard that would be.

build/ARM_FS/mem/ruby/system/Sequencer.cc: In member function 'void
Sequencer::issueRequest(const RubyRequest&)':
build/ARM_FS/mem/ruby/system/Sequencer.cc:616: warning: 'ctype' may be
used uninitialized in this function
build/ARM_FS/mem/ruby/system/Sequencer.cc:653: warning: 'amtype' may
be used uninitialized in this function

Quoting Cron Daemon:


scons: *** [build/ALPHA_SE/cpu/testers/networktest/networktest.fo] Error 1
scons: ***
[build/ALPHA_SE_MOESI_hammer/cpu/testers/networktest/networktest.fo]
Error 1
scons: ***
[build/ALPHA_SE_MESI_CMP_directory/cpu/testers/networktest/networktest.fo]
Error 1
scons: ***
[build/ALPHA_SE_MOESI_CMP_directory/cpu/testers/networktest/networktest.fo]
Error 1
scons: ***
[build/ALPHA_SE_MOESI_CMP_token/cpu/testers/networktest/networktest.fo]
Error 1
scons: *** [build/ALPHA_FS/cpu/testers/networktest/networktest.fo] Error 1
scons: *** [build/MIPS_SE/cpu/testers/networktest/networktest.fo] Error 1
scons: *** [build/POWER_SE/cpu/testers/networktest/networktest.fo] Error 1
scons: *** [build/SPARC_SE/cpu/testers/networktest/networktest.fo] Error 1
scons: *** [build/X86_SE/cpu/testers/networktest/networktest.fo] Error 1
scons: *** [build/X86_FS/cpu/testers/networktest/networktest.fo] Error 1
scons: *** [build/ARM_SE/cpu/testers/networktest/networktest.fo] Error 1
scons: *** [build/ARM_FS/cpu/testers/networktest/networktest.fo] Error 1

See /z/m5/regression/regress-2011-03-22-03:00:01 for details.

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





--

Message: 2
Date: Tue, 22 Mar 2011 14:33:58 -0500 (CDT)
From: Nilay Vaish
To: M5 Developer List
Subject: Re: [m5-dev] Cron
/z/m5/regression/do-regression quick
Message-ID:
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

On Tue, 22 Mar 2011, Gabriel Michael Black wrote:


The two issues below are copied from ARM_FS, but other targets had the same
problems.

These errors are making

Re: [m5-dev] Review Request: my initial implementation of cache flushing

[Somayeh Sardashti]

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

(Updated 2011-03-22 19:33:58.68)


Review request for Default and Brad Beckmann.


Summary
---

my initial implementation of cache flushing


Diffs (updated)
-

  src/cpu/testers/rubytest/Check.hh baf4b5f6782e 
  src/cpu/testers/rubytest/Check.cc baf4b5f6782e 
  src/mem/packet.hh baf4b5f6782e 
  src/mem/packet.cc baf4b5f6782e 
  src/mem/protocol/MOESI_hammer-cache.sm baf4b5f6782e 
  src/mem/protocol/MOESI_hammer-dir.sm baf4b5f6782e 
  src/mem/protocol/MOESI_hammer-msg.sm baf4b5f6782e 
  src/mem/protocol/RubySlicc_Exports.sm baf4b5f6782e 
  src/mem/protocol/RubySlicc_Types.sm baf4b5f6782e 
  src/mem/ruby/slicc_interface/RubyRequest.hh baf4b5f6782e 
  src/mem/ruby/slicc_interface/RubyRequest.cc baf4b5f6782e 
  src/mem/ruby/system/DMASequencer.cc baf4b5f6782e 
  src/mem/ruby/system/RubyPort.cc baf4b5f6782e 
  src/mem/ruby/system/Sequencer.cc baf4b5f6782e 

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


Testing
---

This implementation has passed 10,000,000 ruby test cases, and the MOESI_hammer 
regression tests.


Thanks,

Somayeh

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

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

[Beckmann, Brad]

Korey, if you're deadlock is with running the MOESI_CMP_directory protocol, I'm 
not surprised.  DMA support is pretty much broken in that protocol.  I have 
that fixed and I also fixed the underlining DMA problem.  I'll be pushing the 
fixes momentarily.

Korey and Malek, please pull these changes and confirm they fix your problem.

Brad


> -Original Message-
> From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org]
> On Behalf Of Korey Sewell
> Sent: Friday, March 18, 2011 9:12 AM
> To: M5 Developer List
> Subject: Re: [m5-dev] Ruby FS - DMA Controller problem?
> 
> 
> 
> Why did it work before the block size patch?
> > - When the ChuckGenerator sees the block size is 0, it doesn't split
> > up the request into multiple patches and sends the whole dma request
> > at once.  That is fine because the DMASequencer splits the request
> > into multiple requests and only responds to the dma port when the entire
> request is complete.
> >
> With regards to the old changeset that boots with the block size = 0, I was 
> not
> able to boot a large scale CMP system (more than 16 cores) due to the
> "deadlock threshold" being triggered.
> 
> I'm assuming that Brad has a read on how to fix that problem so I'll probably
> start working on what is causing that deadlock so hopefully we can kind of
> pipeline the bug fixes.
> 
> --
> - 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] Review Request: Ruby: Convert AccessModeType to RubyAccessMode

[Beckmann, Brad]

Nevermind, I understand the reason now.  This looks good to me.

Thanks,

Brad

> -Original Message-
> From: Beckmann, Brad
> Sent: Saturday, March 19, 2011 1:50 PM
> To: 'M5 Developer List'
> Subject: RE: [m5-dev] Review Request: Ruby: Convert AccessModeType to
> RubyAccessMode
> 
> Hi Nilay,
> 
> Why do you want to change the name?  Both names seem equivalent to me.
> 
> Brad
> 
> 
> > -Original Message-
> > From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] On
> > Behalf Of Nilay Vaish
> > Sent: Friday, March 18, 2011 9:55 PM
> > To: Nilay Vaish; Default
> > Subject: [m5-dev] Review Request: Ruby: Convert AccessModeType to
> > RubyAccessMode
> >
> >
> > ---
> > This is an automatically generated e-mail. To reply, visit:
> > http://reviews.m5sim.org/r/601/
> > ---
> >
> > Review request for Default.
> >
> >
> > Summary
> > ---
> >
> > Ruby: Convert AccessModeType to RubyAccessMode
> > This patch converts AccessModeType to RubyAccessMode so that both the
> > protocol dependent and independent code uses the same access mode.
> >
> >
> > Diffs
> > -
> >
> >   src/cpu/testers/rubytest/Check.hh 9a6a02a235f1
> >   src/cpu/testers/rubytest/Check.cc 9a6a02a235f1
> >   src/mem/protocol/MESI_CMP_directory-msg.sm 9a6a02a235f1
> >   src/mem/protocol/MOESI_CMP_directory-msg.sm 9a6a02a235f1
> >   src/mem/protocol/MOESI_CMP_token-L1cache.sm 9a6a02a235f1
> >   src/mem/protocol/MOESI_CMP_token-dir.sm 9a6a02a235f1
> >   src/mem/protocol/MOESI_CMP_token-msg.sm 9a6a02a235f1
> >   src/mem/protocol/RubySlicc_Exports.sm 9a6a02a235f1
> >   src/mem/protocol/RubySlicc_Types.sm 9a6a02a235f1
> >   src/mem/ruby/profiler/AccessTraceForAddress.hh 9a6a02a235f1
> >   src/mem/ruby/profiler/AccessTraceForAddress.cc 9a6a02a235f1
> >   src/mem/ruby/profiler/AddressProfiler.hh 9a6a02a235f1
> >   src/mem/ruby/profiler/AddressProfiler.cc 9a6a02a235f1
> >   src/mem/ruby/profiler/CacheProfiler.hh 9a6a02a235f1
> >   src/mem/ruby/profiler/CacheProfiler.cc 9a6a02a235f1
> >   src/mem/ruby/profiler/Profiler.hh 9a6a02a235f1
> >   src/mem/ruby/slicc_interface/RubyRequest.hh 9a6a02a235f1
> >   src/mem/ruby/system/CacheMemory.hh 9a6a02a235f1
> >   src/mem/ruby/system/CacheMemory.cc 9a6a02a235f1
> >   src/mem/ruby/system/Sequencer.hh 9a6a02a235f1
> >   src/mem/ruby/system/Sequencer.cc 9a6a02a235f1
> >
> > Diff: http://reviews.m5sim.org/r/601/diff
> >
> >
> > Testing
> > ---
> >
> >
> > Thanks,
> >
> > Nilay
> >
> > ___
> > 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] Review Request: Ruby: Convert AccessModeType to RubyAccessMode

[Beckmann, Brad]

Hi Nilay,

Why do you want to change the name?  Both names seem equivalent to me.

Brad


> -Original Message-
> From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] On
> Behalf Of Nilay Vaish
> Sent: Friday, March 18, 2011 9:55 PM
> To: Nilay Vaish; Default
> Subject: [m5-dev] Review Request: Ruby: Convert AccessModeType to
> RubyAccessMode
> 
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/601/
> ---
> 
> Review request for Default.
> 
> 
> Summary
> ---
> 
> Ruby: Convert AccessModeType to RubyAccessMode
> This patch converts AccessModeType to RubyAccessMode so that both the
> protocol dependent and independent code uses the same access mode.
> 
> 
> Diffs
> -
> 
>   src/cpu/testers/rubytest/Check.hh 9a6a02a235f1
>   src/cpu/testers/rubytest/Check.cc 9a6a02a235f1
>   src/mem/protocol/MESI_CMP_directory-msg.sm 9a6a02a235f1
>   src/mem/protocol/MOESI_CMP_directory-msg.sm 9a6a02a235f1
>   src/mem/protocol/MOESI_CMP_token-L1cache.sm 9a6a02a235f1
>   src/mem/protocol/MOESI_CMP_token-dir.sm 9a6a02a235f1
>   src/mem/protocol/MOESI_CMP_token-msg.sm 9a6a02a235f1
>   src/mem/protocol/RubySlicc_Exports.sm 9a6a02a235f1
>   src/mem/protocol/RubySlicc_Types.sm 9a6a02a235f1
>   src/mem/ruby/profiler/AccessTraceForAddress.hh 9a6a02a235f1
>   src/mem/ruby/profiler/AccessTraceForAddress.cc 9a6a02a235f1
>   src/mem/ruby/profiler/AddressProfiler.hh 9a6a02a235f1
>   src/mem/ruby/profiler/AddressProfiler.cc 9a6a02a235f1
>   src/mem/ruby/profiler/CacheProfiler.hh 9a6a02a235f1
>   src/mem/ruby/profiler/CacheProfiler.cc 9a6a02a235f1
>   src/mem/ruby/profiler/Profiler.hh 9a6a02a235f1
>   src/mem/ruby/slicc_interface/RubyRequest.hh 9a6a02a235f1
>   src/mem/ruby/system/CacheMemory.hh 9a6a02a235f1
>   src/mem/ruby/system/CacheMemory.cc 9a6a02a235f1
>   src/mem/ruby/system/Sequencer.hh 9a6a02a235f1
>   src/mem/ruby/system/Sequencer.cc 9a6a02a235f1
> 
> Diff: http://reviews.m5sim.org/r/601/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Nilay
> 
> ___
> 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] Ruby random tester failing with MESI_CMP_directory?

[Lisa Hsu]

Hi Arka,

My repo it not the current tip, but the tip is Nilay's push removing
CacheMsg, so it's pretty close. I've been running X86_SE_MESI_CMP_directory
with the random tester for maybe 10 or 15 minutes now, and it hasn't died.
 Since yours died "immediately", I would assume that I won't be able to
reproduce.

What's your tip, is it last night's pushes?
Lisa

On Tue, Mar 22, 2011 at 6:06 PM, Nilay  wrote:

> On Tue, March 22, 2011 6:28 pm, Arkaprava Basu wrote:
> > Hi,
> >
> >   I just updated a clean gem5 repo, compiled MESI_CMP_directory and
> > tried to run ruby random tester but it immediately failed as follows.
> > Can any body reproduce this?
> >
> > Thanks
> > Arka
> >
> >
>
> ALPHA is working fine for 1 loads with 4 processors. Since your
> testing with ruby random tester, would the processor architecture even
> come in to play?
>
> --
> Nilay
>
> ___
> 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] Ruby random tester failing with MESI_CMP_directory?

[Nilay]

On Tue, March 22, 2011 6:28 pm, Arkaprava Basu wrote:
> Hi,
>
>   I just updated a clean gem5 repo, compiled MESI_CMP_directory and
> tried to run ruby random tester but it immediately failed as follows.
> Can any body reproduce this?
>
> Thanks
> Arka
>
>

ALPHA is working fine for 1 loads with 4 processors. Since your
testing with ruby random tester, would the processor architecture even
come in to play?

--
Nilay

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

[m5-dev] Ruby random tester failing with MESI_CMP_directory?

[Arkaprava Basu]

Hi,

 I just updated a clean gem5 repo, compiled MESI_CMP_directory and 
tried to run ruby random tester but it immediately failed as follows. 
Can any body reproduce this?


Thanks
Arka


build/X86_SE_MESI_CMP_directory/m5.debug 
configs/example/ruby_random_test.py -l 10 -n 4

M5 Simulator System

Copyright (c) 2001-2008
The Regents of The University of Michigan
All Rights Reserved


M5 compiled Mar 22 2011 17:56:26
M5 started Mar 22 2011 17:58:16
M5 executing on rockstar.cs.wisc.edu
command line: build/X86_SE_MESI_CMP_directory/m5.debug 
configs/example/ruby_random_test.py -l 10 -n 4

Global frequency set at 10 ticks per second
info: Entering event queue @ 0.  Starting simulation...
fatal: Invalid transition
system.dir_cntrl0 time: 1125 addr: [0x400, line 0x400] event: Fetch state: M
 @ cycle 1125
[doTransitionWorker:build/X86_SE_MESI_CMP_directory/mem/protocol/Directory_Transitions.cc, 
line 234]

Memory Usage: 297516 KBytes
For more information see: http://www.m5sim.org/fatal/23f196b2

___
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

[Beckmann, Brad]

I sent Tushar an email this morning regarding this, hoping to catch him before 
he went to bed (he's currently in Singapore).  Unfortunately he hasn't 
responded.

Hopefully he'll get to this when he wakes up in a few hours.  If he doesn't, 
I'll take a look at it tomorrow morning.  I don't have time to do it today.

Brad


> -Original Message-
> From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org]
> On Behalf Of Gabe Black
> Sent: Tuesday, March 22, 2011 1:04 PM
> To: m5-dev@m5sim.org
> Subject: Re: [m5-dev] Cron  /z/m5/regression/do-
> regression quick
> 
> You may already be taking care of this, but networktest.cc also had an error
> (ambiguous use of the pow function) that made all the regressions fail. That
> needs to be fixed quickly, regardless of what happens with the warnings or
> who originally worked on the code. Also, code that doesn't compile should
> really never have been committed in the first place. It couldn't have been
> tested since it couldn't have been run.
> 
> Gabe
> 
> On 03/22/11 15:46, Nilay Vaish wrote:
> > On Tue, 22 Mar 2011, nathan binkert wrote:
> >
> >>> The warnings related to networktest.cc got added yesterday.
> >
> > Tushar should take care of the warnings related to networktest.cc.
> >
> >>
> >> 
> >>
> >>> These I think have been around for quite a while.
> >>
> >> Either way, we should be eliminating warnings.
> >>
> >
> > I will commit a patch to eliminate the Sequencer related warnings.
> >
> > --
> > Nilay
> > ___
> > 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


___
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

[Gabe Black]

You may already be taking care of this, but networktest.cc also had an
error (ambiguous use of the pow function) that made all the regressions
fail. That needs to be fixed quickly, regardless of what happens with
the warnings or who originally worked on the code. Also, code that
doesn't compile should really never have been committed in the first
place. It couldn't have been tested since it couldn't have been run.

Gabe

On 03/22/11 15:46, Nilay Vaish wrote:
> On Tue, 22 Mar 2011, nathan binkert wrote:
>
>>> The warnings related to networktest.cc got added yesterday.
>
> Tushar should take care of the warnings related to networktest.cc.
>
>>
>> 
>>
>>> These I think have been around for quite a while.
>>
>> Either way, we should be eliminating warnings.
>>
>
> I will commit a patch to eliminate the Sequencer related warnings.
>
> -- 
> Nilay
> ___
> 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

[Nilay Vaish]

On Tue, 22 Mar 2011, nathan binkert wrote:


The warnings related to networktest.cc got added yesterday.


Tushar should take care of the warnings related to networktest.cc.






These I think have been around for quite a while.


Either way, we should be eliminating warnings.



I will commit a patch to eliminate the Sequencer related warnings.

--
Nilay
___
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

[nathan binkert]

> The warnings related to networktest.cc got added yesterday.



> These I think have been around for quite a while.

Either way, we should be eliminating warnings.

  Nate
___
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

[Nilay Vaish]

On Tue, 22 Mar 2011, Gabriel Michael Black wrote:

The two issues below are copied from ARM_FS, but other targets had the same 
problems.


These errors are making the build fail.

build/ARM_FS/cpu/testers/networktest/networktest.cc: In member function 'void 
NetworkTest::completeRequest(Packet*)':
build/ARM_FS/cpu/testers/networktest/networktest.cc:160: warning: unused 
variable 'req'
build/ARM_FS/cpu/testers/networktest/networktest.cc: In member function 'void 
NetworkTest::tick()':
build/ARM_FS/cpu/testers/networktest/networktest.cc:194: error: call of 
overloaded 'pow(int, int&)' is ambiguous



These warnings should probably be cleaned up too, although I don't know how 
long they've been there or how hard that would be.




The warnings related to networktest.cc got added yesterday.



build/ARM_FS/mem/ruby/system/Sequencer.cc: In member function 'void 
Sequencer::issueRequest(const RubyRequest&)':
build/ARM_FS/mem/ruby/system/Sequencer.cc:616: warning: 'ctype' may be used 
uninitialized in this function
build/ARM_FS/mem/ruby/system/Sequencer.cc:653: warning: 'amtype' may be used 
uninitialized in this function




These I think have been around for quite a while.

--
Nilay
___
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

[Gabriel Michael Black]

The two issues below are copied from ARM_FS, but other targets had the  
same problems.


These errors are making the build fail.

build/ARM_FS/cpu/testers/networktest/networktest.cc: In member  
function 'void NetworkTest::completeRequest(Packet*)':
build/ARM_FS/cpu/testers/networktest/networktest.cc:160: warning:  
unused variable 'req'
build/ARM_FS/cpu/testers/networktest/networktest.cc: In member  
function 'void NetworkTest::tick()':
build/ARM_FS/cpu/testers/networktest/networktest.cc:194: error: call  
of overloaded 'pow(int, int&)' is ambiguous



These warnings should probably be cleaned up too, although I don't  
know how long they've been there or how hard that would be.


build/ARM_FS/mem/ruby/system/Sequencer.cc: In member function 'void  
Sequencer::issueRequest(const RubyRequest&)':
build/ARM_FS/mem/ruby/system/Sequencer.cc:616: warning: 'ctype' may be  
used uninitialized in this function
build/ARM_FS/mem/ruby/system/Sequencer.cc:653: warning: 'amtype' may  
be used uninitialized in this function


Quoting Cron Daemon :


scons: *** [build/ALPHA_SE/cpu/testers/networktest/networktest.fo] Error 1
scons: ***  
[build/ALPHA_SE_MOESI_hammer/cpu/testers/networktest/networktest.fo]  
Error 1
scons: ***  
[build/ALPHA_SE_MESI_CMP_directory/cpu/testers/networktest/networktest.fo]  
Error 1
scons: ***  
[build/ALPHA_SE_MOESI_CMP_directory/cpu/testers/networktest/networktest.fo]  
Error 1
scons: ***  
[build/ALPHA_SE_MOESI_CMP_token/cpu/testers/networktest/networktest.fo]  
Error 1

scons: *** [build/ALPHA_FS/cpu/testers/networktest/networktest.fo] Error 1
scons: *** [build/MIPS_SE/cpu/testers/networktest/networktest.fo] Error 1
scons: *** [build/POWER_SE/cpu/testers/networktest/networktest.fo] Error 1
scons: *** [build/SPARC_SE/cpu/testers/networktest/networktest.fo] Error 1
scons: *** [build/X86_SE/cpu/testers/networktest/networktest.fo] Error 1
scons: *** [build/X86_FS/cpu/testers/networktest/networktest.fo] Error 1
scons: *** [build/ARM_SE/cpu/testers/networktest/networktest.fo] Error 1
scons: *** [build/ARM_FS/cpu/testers/networktest/networktest.fo] Error 1

See /z/m5/regression/regress-2011-03-22-03:00:01 for details.

___
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

[m5-dev] changeset in m5: Ruby: Remove CacheMsg class from SLICC

[Nilay Vaish]

changeset e21f6e70169e in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=e21f6e70169e
description:
Ruby: Remove CacheMsg class from SLICC
The goal of the patch is to do away with the CacheMsg class currently 
in use
in coherence protocols. In place of CacheMsg, the RubyRequest class 
will used.
This class is already present in slicc_interface/RubyRequest.hh. In 
fact,
objects of class CacheMsg are generated by copying values from a 
RubyRequest
object.

diffstat:

 src/mem/protocol/MESI_CMP_directory-L1cache.sm   |   12 +-
 src/mem/protocol/MI_example-cache.sm |6 +-
 src/mem/protocol/MOESI_CMP_directory-L1cache.sm  |   10 +-
 src/mem/protocol/MOESI_CMP_token-L1cache.sm  |   12 +-
 src/mem/protocol/MOESI_hammer-cache.sm   |8 +-
 src/mem/protocol/Network_test-cache.sm   |4 +-
 src/mem/protocol/RubySlicc_Exports.sm|   11 -
 src/mem/protocol/RubySlicc_Profiler.sm   |4 +-
 src/mem/protocol/RubySlicc_Types.sm  |   12 +-
 src/mem/ruby/profiler/AddressProfiler.cc |2 +-
 src/mem/ruby/profiler/AddressProfiler.hh |2 +-
 src/mem/ruby/profiler/Profiler.cc|4 +-
 src/mem/ruby/profiler/Profiler.hh|4 +-
 src/mem/ruby/recorder/TraceRecord.cc |2 +-
 src/mem/ruby/slicc_interface/RubyRequest.cc  |   41 +--
 src/mem/ruby/slicc_interface/RubyRequest.hh  |  104 +++-
 src/mem/ruby/slicc_interface/RubySlicc_Profiler_interface.hh |4 +-
 src/mem/ruby/slicc_interface/RubySlicc_Util.hh   |2 -
 src/mem/ruby/system/CacheMemory.cc   |2 +-
 src/mem/ruby/system/CacheMemory.hh   |4 +-
 src/mem/ruby/system/DMASequencer.cc  |6 +-
 src/mem/ruby/system/RubyPort.cc  |2 +-
 src/mem/ruby/system/Sequencer.cc |  116 +-
 23 files changed, 208 insertions(+), 166 deletions(-)

diffs (truncated from 893 to 300 lines):

diff -r 2c47dc111abd -r e21f6e70169e 
src/mem/protocol/MESI_CMP_directory-L1cache.sm
--- a/src/mem/protocol/MESI_CMP_directory-L1cache.smMon Mar 21 22:51:59 
2011 -0400
+++ b/src/mem/protocol/MESI_CMP_directory-L1cache.smTue Mar 22 06:41:54 
2011 -0500
@@ -267,9 +267,9 @@
   }
 
   // Mandatory Queue betweens Node's CPU and it's L1 caches
-  in_port(mandatoryQueue_in, CacheMsg, mandatoryQueue, desc="...") {
+  in_port(mandatoryQueue_in, RubyRequest, mandatoryQueue, desc="...") {
 if (mandatoryQueue_in.isReady()) {
-  peek(mandatoryQueue_in, CacheMsg, block_on="LineAddress") {
+  peek(mandatoryQueue_in, RubyRequest, block_on="LineAddress") {
 
 // Check for data access to blocks in I-cache and ifetchs to blocks in 
D-cache
 
@@ -338,7 +338,7 @@
 
   // ACTIONS
   action(a_issueGETS, "a", desc="Issue GETS") {
-peek(mandatoryQueue_in, CacheMsg) {
+peek(mandatoryQueue_in, RubyRequest) {
   enqueue(requestIntraChipL1Network_out, RequestMsg, 
latency=l1_request_latency) {
 out_msg.Address := address;
 out_msg.Type := CoherenceRequestType:GETS;
@@ -355,7 +355,7 @@
   }
 
   action(ai_issueGETINSTR, "ai", desc="Issue GETINSTR") {
-peek(mandatoryQueue_in, CacheMsg) {
+peek(mandatoryQueue_in, RubyRequest) {
   enqueue(requestIntraChipL1Network_out, RequestMsg, 
latency=l1_request_latency) {
 out_msg.Address := address;
 out_msg.Type := CoherenceRequestType:GET_INSTR;
@@ -373,7 +373,7 @@
 
 
   action(b_issueGETX, "b", desc="Issue GETX") {
-peek(mandatoryQueue_in, CacheMsg) {
+peek(mandatoryQueue_in, RubyRequest) {
   enqueue(requestIntraChipL1Network_out, RequestMsg, 
latency=l1_request_latency) {
 out_msg.Address := address;
 out_msg.Type := CoherenceRequestType:GETX;
@@ -391,7 +391,7 @@
   }
 
   action(c_issueUPGRADE, "c", desc="Issue GETX") {
-peek(mandatoryQueue_in, CacheMsg) {
+peek(mandatoryQueue_in, RubyRequest) {
   enqueue(requestIntraChipL1Network_out, RequestMsg, latency= 
l1_request_latency) {
 out_msg.Address := address;
 out_msg.Type := CoherenceRequestType:UPGRADE;
diff -r 2c47dc111abd -r e21f6e70169e src/mem/protocol/MI_example-cache.sm
--- a/src/mem/protocol/MI_example-cache.sm  Mon Mar 21 22:51:59 2011 -0400
+++ b/src/mem/protocol/MI_example-cache.sm  Tue Mar 22 06:41:54 2011 -0500
@@ -181,9 +181,9 @@
   }
 
 // Mandatory Queue
-  in_port(mandatoryQueue_in, CacheMsg, mandatoryQueue, desc="...") {
+  in_port(mandatoryQueue_in, RubyRequest, mandatoryQueue, desc="...") {
 if (mandatoryQueue_in.isReady()) {
-  peek(mandatoryQueue_in, CacheMsg, block_on="LineAddress") {
+  peek(mandato

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

[Cron Daemon]

scons: *** [build/ALPHA_SE/cpu/testers/networktest/networktest.fo] Error 1
scons: *** [build/ALPHA_SE_MOESI_hammer/cpu/testers/networktest/networktest.fo] 
Error 1
scons: *** 
[build/ALPHA_SE_MESI_CMP_directory/cpu/testers/networktest/networktest.fo] 
Error 1
scons: *** 
[build/ALPHA_SE_MOESI_CMP_directory/cpu/testers/networktest/networktest.fo] 
Error 1
scons: *** 
[build/ALPHA_SE_MOESI_CMP_token/cpu/testers/networktest/networktest.fo] Error 1
scons: *** [build/ALPHA_FS/cpu/testers/networktest/networktest.fo] Error 1
scons: *** [build/MIPS_SE/cpu/testers/networktest/networktest.fo] Error 1
scons: *** [build/POWER_SE/cpu/testers/networktest/networktest.fo] Error 1
scons: *** [build/SPARC_SE/cpu/testers/networktest/networktest.fo] Error 1
scons: *** [build/X86_SE/cpu/testers/networktest/networktest.fo] Error 1
scons: *** [build/X86_FS/cpu/testers/networktest/networktest.fo] Error 1
scons: *** [build/ARM_SE/cpu/testers/networktest/networktest.fo] Error 1
scons: *** [build/ARM_FS/cpu/testers/networktest/networktest.fo] Error 1

See /z/m5/regression/regress-2011-03-22-03:00:01 for details.

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