date:20110120

Re: [m5-dev] changeset in m5: checkpointing: fix bug from curTick accessor co...

2011-01-20 Thread Gabe Black

 From time to time It seems to be that we need to serialize something
but call it something other than its variable name. Would it make sense
to add SERIALIZE_*_AS macros that take a name argument as well? It's not
that hard to create a temporary variable or use those param functions
directly, but it would at least make things look more consistent to
always (or almost always) use SERIALIZE_FOO.

Gabe

On 01/20/11 22:11, Steve Reinhardt wrote:
> changeset 494b5426e70d in /z/repo/m5
> details: http://repo.m5sim.org/m5?cmd=changeset;node=494b5426e70d
> description:
>   checkpointing: fix bug from curTick accessor conversion.
>
>   Regex replacement of curTick with curTick() accidentally
>   changed checkpoint key string for serialization but not
>   for unserialization.
>
> diffstat:
>
>  src/sim/serialize.cc |  2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diffs (12 lines):
>
> diff -r f84bfd45d607 -r 494b5426e70d src/sim/serialize.cc
> --- a/src/sim/serialize.ccWed Jan 19 16:22:23 2011 -0800
> +++ b/src/sim/serialize.ccThu Jan 20 22:13:33 2011 -0800
> @@ -400,7 +400,7 @@
>  Globals::serialize(ostream &os)
>  {
>  nameOut(os);
> -SERIALIZE_SCALAR(curTick());
> +paramOut(os, "curTick", curTick());
>  
>  nameOut(os, "MainEventQueue");
>  mainEventQueue.serialize(os);
> ___
> 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] 3 Bugs in the checkpoint_restore for spec2006

2011-01-20 Thread Steve Reinhardt

Hi Rick,

Thanks for figuring this out.  The last one is clearly just my dumb mistake;
I just committed a fix.  The serialization/unserialization of mode is an
obvious enough oversight too.

I'm not quite so sure about the dup fix though... I think the original
sim_fd_obj() is doing the right thing, it's just that perhaps that's not
what dupFunc() needs or wants.  That just means dupFunc() shouldn't be
calling it though.  Maybe dupFunc() needs to call a different function that
doesn't exist.  However, I'm not so sure about that, because I'm not
convinced the overall strategy for checkpointing and restoring dup'd fds is
even right.  At first glance, it looks like when we unserialize a pair of
dup'd fds, we'll end up opening the file twice, rather than calling dup()
again, which seems more correct.

Steve

On Thu, Jan 20, 2011 at 11:41 AM, Richard Strong wrote:

> Hi all,
>
> I uncovered 3 bugs when trying to resume in ALPHA_SE from a checkpoint for
> the spec2006 benchmarks. They are:
>
> (1) Unserializing curTick failed because the checkpoint file wrote
> curTick()=, but the unserializing code was expecting curTick=
>
> (2) The mode bit was not being stored in the file descriptor checkpoint. I
> added a feature to store the mode bit.
>
> (3) The dup function was duplicating the wrong file descriptor.
>
> Let me know what you think, I give the diff below along with a traceflag
> that allowed me to find the problem.
>
> Best,
> -Rick
>
> diff --git a/src/sim/SConscript b/src/sim/SConscript
> --- a/src/sim/SConscript
> +++ b/src/sim/SConscript
> @@ -77,3 +77,4 @@
>  TraceFlag('Thread')
>  TraceFlag('Timer')
>  TraceFlag('VtoPhys')
> +TraceFlag('FileDescriptors')
> diff --git a/src/sim/process.cc b/src/sim/process.cc
> --- a/src/sim/process.cc
> +++ b/src/sim/process.cc
> @@ -268,6 +268,7 @@
>  int
>  Process::alloc_fd(int sim_fd, string filename, int flags, int mode, bool
> pipe)
>  {
> +DPRINTF(FileDescriptors, "alloc_fd fd:%d filename:%s\n", sim_fd,
> filename);
>  // in case open() returns an error, don't allocate a new fd
>  if (sim_fd == -1)
>  return -1;
> @@ -295,6 +296,7 @@
>  void
>  Process::free_fd(int tgt_fd)
>  {
> +DPRINTF(FileDescriptors, "free_fd fd:%d name:%s\n", tgt_fd, "NULL");
>  Process::FdMap *fdo = &fd_map[tgt_fd];
>  if (fdo->fd == -1)
>  warn("Process::free_fd: request to free unused fd %d", tgt_fd);
> @@ -324,8 +326,16 @@
>  {
>  if (tgt_fd > MAX_FD)
>  panic("sim_fd_obj called in fd out of range.");
> +
>
> -return &fd_map[tgt_fd];
> +//return &fd_map[tgt_fd];
> +for (int x = 0; x <= MAX_FD; x++) {
> +   if (fd_map[x].fd == tgt_fd){
> +   return &fd_map[x];
> +   }
> + }
> + panic("sim_fd_obj could not find system fd.");
> + return NULL;
>  }
>
>  bool
> @@ -458,6 +468,7 @@
>  if (fdo->fd != -1) {
>  fdo->fileOffset = lseek(fdo->fd, 0, SEEK_CUR);
>  } else {
> +DPRINTF(FileDescriptors, "find_file_offsets fd:%d
> filename:%s\n", fdo->fd, fdo->filename);
>  fdo->filename = "NULL";
>  fdo->fileOffset = 0;
>  }
> @@ -480,6 +491,7 @@
>  SERIALIZE_SCALAR(flags);
>  SERIALIZE_SCALAR(readPipeSource);
>  SERIALIZE_SCALAR(fileOffset);
> +SERIALIZE_SCALAR(mode);
>  }
>
>  void
> @@ -491,6 +503,7 @@
>  UNSERIALIZE_SCALAR(flags);
>  UNSERIALIZE_SCALAR(readPipeSource);
>  UNSERIALIZE_SCALAR(fileOffset);
> +UNSERIALIZE_SCALAR(mode);
>  }
>
>  void
> diff --git a/src/sim/serialize.cc b/src/sim/serialize.cc
> --- a/src/sim/serialize.cc
> +++ b/src/sim/serialize.cc
> @@ -411,7 +411,7 @@
>  {
>  const string §ion = name();
>  Tick tick;
> -paramIn(cp, section, "curTick", tick);
> +paramIn(cp, section, "curTick()", tick);
>  curTick(tick);
>
>  mainEventQueue.unserialize(cp, "MainEventQueue");
>
>
> ___
> 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: checkpointing: fix bug from curTick accessor co...

2011-01-20 Thread Steve Reinhardt

changeset 494b5426e70d in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=494b5426e70d
description:
checkpointing: fix bug from curTick accessor conversion.

Regex replacement of curTick with curTick() accidentally
changed checkpoint key string for serialization but not
for unserialization.

diffstat:

 src/sim/serialize.cc |  2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diffs (12 lines):

diff -r f84bfd45d607 -r 494b5426e70d src/sim/serialize.cc
--- a/src/sim/serialize.cc  Wed Jan 19 16:22:23 2011 -0800
+++ b/src/sim/serialize.cc  Thu Jan 20 22:13:33 2011 -0800
@@ -400,7 +400,7 @@
 Globals::serialize(ostream &os)
 {
 nameOut(os);
-SERIALIZE_SCALAR(curTick());
+paramOut(os, "curTick", curTick());
 
 nameOut(os, "MainEventQueue");
 mainEventQueue.serialize(os);
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

Re: [m5-dev] 3 Bugs in the checkpoint_restore for spec2006

2011-01-20 Thread Ali Saidi



Rick, 

Could you post your diff on review board? 

Thanks, 

Ali


On Thu, 20 Jan 2011 11:41:01 -0800, Richard Strong  wrote:  

Hi
all,

I uncovered 3 bugs when trying to resume in ALPHA_SE from a
checkpoint for the spec2006 benchmarks. They are:

(1) Unserializing
curTick failed because the checkpoint file wrote curTick()=, but the
unserializing code was expecting curTick=

(2) The mode bit was not
being stored in the file descriptor checkpoint. I added a feature to
store the mode bit.

(3) The dup function was duplicating the wrong file
descriptor. 

Let me know what you think, I give the diff below along
with a traceflag that allowed me to find the problem.

Best,
-Rick

diff
--git a/src/sim/SConscript b/src/sim/SConscript
---
a/src/sim/SConscript
+++ b/src/sim/SConscript
@@ -77,3 +77,4 @@

TraceFlag('Thread')
 TraceFlag('Timer')

TraceFlag('VtoPhys')
+TraceFlag('FileDescriptors')
diff --git
a/src/sim/process.cc b/src/sim/process.cc
--- a/src/sim/process.cc
+++
b/src/sim/process.cc
@@ -268,6 +268,7 @@
 int
 Process::alloc_fd(int
sim_fd, string filename, int flags, int mode, bool pipe)
 {
+
DPRINTF(FileDescriptors, "alloc_fd fd:%d filename:%sn", sim_fd,
filename);
 // in case open() returns an error, don't allocate a new fd

if (sim_fd == -1)
 return -1;
 @@ -295,6 +296,7 @@
 void

Process::free_fd(int tgt_fd)
 {
+ DPRINTF(FileDescriptors, "free_fd
fd:%d name:%sn", tgt_fd, "NULL");
 Process::FdMap *fdo =
&fd_map[tgt_fd];
 if (fdo->fd == -1)
 warn("Process::free_fd: request to
free unused fd %d", tgt_fd);
@@ -324,8 +326,16 @@
 {
 if (tgt_fd >
MAX_FD)
 panic("sim_fd_obj called in fd out of range.");
+ 

- return
&fd_map[tgt_fd];
+ //return &fd_map[tgt_fd];
+ for (int x = 0; x fd !=
-1) {
 fdo->fileOffset = lseek(fdo->fd, 0, SEEK_CUR);
 } else {
+
DPRINTF(FileDescriptors, "find_file_offsets fd:%d filename:%sn",
fdo->fd, fdo->filename);
 fdo->filename = "NULL";
 fdo->fileOffset = 0;

}
@@ -480,6 +491,7 @@
 SERIALIZE_SCALAR(flags);

SERIALIZE_SCALAR(readPipeSource);
 SERIALIZE_SCALAR(fileOffset);
+
SERIALIZE_SCALAR(mode);
 }

 void
@@ -491,6 +503,7 @@

UNSERIALIZE_SCALAR(flags);
 UNSERIALIZE_SCALAR(readPipeSource);

UNSERIALIZE_SCALAR(fileOffset);
+ UNSERIALIZE_SCALAR(mode);
 }


void
diff --git a/src/sim/serialize.cc b/src/sim/serialize.cc
 ---
a/src/sim/serialize.cc
+++ b/src/sim/serialize.cc
@@ -411,7 +411,7 @@

{
 const string §ion = name();
 Tick tick;
- paramIn(cp, section,
"curTick", tick);
+ paramIn(cp, section, "curTick()", tick);

curTick(tick);

 mainEventQueue.unserialize(cp, "MainEventQueue");

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

Re: [m5-dev] Review Request: x86: Timing support for pagetable walker

2011-01-20 Thread Brad Beckmann


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

(Updated 2011-01-20 16:57:10.835752)


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


Summary
---

x86: Timing support for pagetable walker

Move page table walker state to its own object type, and make the
walker instantiate state for each outstanding walk. By storing the
states in a queue, the walker is able to handle multiple outstanding
timing requests. Note that functional walks use separate state
elements.


Diffs (updated)
-

  src/arch/x86/tlb.hh 9f9e10967912 
  src/arch/x86/tlb.cc 9f9e10967912 
  src/arch/x86/pagetable_walker.cc 9f9e10967912 
  src/arch/x86/pagetable_walker.hh 9f9e10967912 

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


Testing
---


Thanks,

Brad

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

Re: [m5-dev] Review Request: x86: implements vtophys

2011-01-20 Thread Brad Beckmann


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

(Updated 2011-01-20 16:52:39.628824)


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


Summary
---

x86: implements vtophys

Calls walker to look up virt. to phys. page mapping


Diffs (updated)
-

  src/arch/x86/vtophys.cc 9f9e10967912 
  src/arch/x86/vtophys.hh 9f9e10967912 

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


Testing
---


Thanks,

Brad

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

Re: [m5-dev] Error in Simulating Mesh Network

2011-01-20 Thread Beckmann, Brad

Hi Nilay,

Yes, I am aware of this problem and one of the patches 
(http://reviews.m5sim.org/r/381/) I'm planning to check in does fix this.  
Unfortunately, those patches are being hung up because I need to do some more 
work on another one of them and right now I don't have any time to do so.   As 
you can see from the patch, it is a very simple fix, so you may want to do it 
locally if it blocking you.

Brad


> -Original Message-
> From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org]
> On Behalf Of Nilay Vaish
> Sent: Thursday, January 20, 2011 6:16 AM
> To: m5-dev@m5sim.org
> Subject: [m5-dev] Error in Simulating Mesh Network
> 
> Brad, I tried simulating a mesh network with four processors.
> 
> ./build/ALPHA_FS_MOESI_hammer/m5.prof ./configs/example/ruby_fs.py -
> -maxtick 2000 -n 4 --topology Mesh --mesh-rows 2 --num-l2cache 4
> --num-dir 4
> 
> I receive the following error:
> 
> panic: FIFO ordering violated: [MessageBuffer:  consumer-yes [ [71227521,
> 870, 1; ] ]] [Version 1, L1Cache, triggerQueue_in]
>   name: [Version 1, L1Cache, triggerQueue_in] current time: 71227512 delta:
> 1 arrival_time: 71227513 last arrival_time: 71227521
>   @ cycle 35613756000
> [enqueue:build/ALPHA_FS_MOESI_hammer/mem/ruby/buffers/MessageB
> uffer.cc,
> line 198]
> 
> Do you think that the options I have specified should work correctly?
> 
> 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: Remove CacheMsg class from SLICC

2011-01-20 Thread Brad Beckmann


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


I've only had a chance to briefly review this, but I do have a couple comments:
- The hammer cache changes didn't seem to upload cleanly.  Can you try to post 
them again?
- I just want to confirm that the libruby interface is still useful to you all 
at Wisconsin, correct?  I just want to make sure I understand why the libruby 
files exist after your change.  Is it possible to eliminate at least a few of 
these functions? For example the libruby_init() function that takes a 
configuration file name as an argument?

- Brad


On 2011-01-20 14:06:16, Nilay Vaish wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/327/
> ---
> 
> (Updated 2011-01-20 14:06:16)
> 
> 
> Review request for Default.
> 
> 
> Summary
> ---
> 
> 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 libruby.hh. In fact, objects of class 
> CacheMsg are generated by copying values from a RubyRequest object.
> 
> This is not complete as of yet. I am facing some difficulty in handling the 
> RefCountingPtr. To me it seems that I am creating the reference correctly. 
> So, the object gets deleted before all the references have gone out of scope.
> 
> 
> Diffs
> -
> 
>   src/cpu/testers/rubytest/RubyTester.hh UNKNOWN 
>   src/mem/protocol/MOESI_hammer-cache.sm UNKNOWN 
>   src/mem/protocol/RubySlicc_Exports.sm UNKNOWN 
>   src/mem/protocol/RubySlicc_Profiler.sm UNKNOWN 
>   src/mem/protocol/RubySlicc_Types.sm UNKNOWN 
>   src/mem/ruby/SConscript UNKNOWN 
>   src/mem/ruby/common/Address.hh UNKNOWN 
>   src/mem/ruby/common/Address.cc UNKNOWN 
>   src/mem/ruby/common/DataBlock.hh UNKNOWN 
>   src/mem/ruby/common/DataBlock.cc UNKNOWN 
>   src/mem/ruby/filters/BlockBloomFilter.cc UNKNOWN 
>   src/mem/ruby/filters/BulkBloomFilter.cc UNKNOWN 
>   src/mem/ruby/filters/LSB_CountingBloomFilter.cc UNKNOWN 
>   src/mem/ruby/filters/MultiGrainBloomFilter.cc UNKNOWN 
>   src/mem/ruby/filters/NonCountingBloomFilter.cc UNKNOWN 
>   src/mem/ruby/libruby.hh UNKNOWN 
>   src/mem/ruby/libruby.cc UNKNOWN 
>   src/mem/ruby/libruby_internal.hh UNKNOWN 
>   src/mem/ruby/profiler/AccessTraceForAddress.cc UNKNOWN 
>   src/mem/ruby/profiler/AddressProfiler.hh UNKNOWN 
>   src/mem/ruby/profiler/AddressProfiler.cc UNKNOWN 
>   src/mem/ruby/profiler/Profiler.hh UNKNOWN 
>   src/mem/ruby/profiler/Profiler.cc UNKNOWN 
>   src/mem/ruby/recorder/CacheRecorder.hh UNKNOWN 
>   src/mem/ruby/recorder/CacheRecorder.cc UNKNOWN 
>   src/mem/ruby/recorder/TraceRecord.hh UNKNOWN 
>   src/mem/ruby/recorder/TraceRecord.cc UNKNOWN 
>   src/mem/ruby/recorder/Tracer.hh UNKNOWN 
>   src/mem/ruby/recorder/Tracer.cc UNKNOWN 
>   src/mem/ruby/slicc_interface/RubyRequest.hh PRE-CREATION 
>   src/mem/ruby/slicc_interface/RubySlicc_Profiler_interface.hh UNKNOWN 
>   src/mem/ruby/slicc_interface/RubySlicc_Util.hh UNKNOWN 
>   src/mem/ruby/slicc_interface/SConscript UNKNOWN 
>   src/mem/ruby/storebuffer/stb_interface.cc UNKNOWN 
>   src/mem/ruby/storebuffer/storebuffer.cc UNKNOWN 
>   src/mem/ruby/system/CacheMemory.hh UNKNOWN 
>   src/mem/ruby/system/CacheMemory.cc UNKNOWN 
>   src/mem/ruby/system/DMASequencer.hh UNKNOWN 
>   src/mem/ruby/system/DMASequencer.cc UNKNOWN 
>   src/mem/ruby/system/PerfectCacheMemory.hh UNKNOWN 
>   src/mem/ruby/system/RubyPort.hh UNKNOWN 
>   src/mem/ruby/system/RubyPort.cc UNKNOWN 
>   src/mem/ruby/system/Sequencer.hh UNKNOWN 
>   src/mem/ruby/system/Sequencer.cc UNKNOWN 
>   src/mem/ruby/system/SparseMemory.cc UNKNOWN 
>   src/mem/slicc/parser.py UNKNOWN 
> 
> Diff: http://reviews.m5sim.org/r/327/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Nilay
> 
>

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

Re: [m5-dev] Error in Simulating Mesh Network

2011-01-20 Thread Joel Hestness

Hi Nilay,
  I believe that this error is fixed in one of the patches that I worked on
while at AMD.  Brad has pushed it up for review:
http://reviews.m5sim.org/r/381/.  It's a one line fix.
  Hope this helps,
  Joel


On Thu, Jan 20, 2011 at 8:15 AM, Nilay Vaish  wrote:

> Brad, I tried simulating a mesh network with four processors.
>
> ./build/ALPHA_FS_MOESI_hammer/m5.prof ./configs/example/ruby_fs.py
> --maxtick 2000 -n 4 --topology Mesh --mesh-rows 2 --num-l2cache 4
> --num-dir 4
>
> I receive the following error:
>
> panic: FIFO ordering violated: [MessageBuffer:  consumer-yes [ [71227521,
> 870, 1; ] ]] [Version 1, L1Cache, triggerQueue_in]
>  name: [Version 1, L1Cache, triggerQueue_in] current time: 71227512 delta:
> 1 arrival_time: 71227513 last arrival_time: 71227521
>  @ cycle 35613756000
> [enqueue:build/ALPHA_FS_MOESI_hammer/mem/ruby/buffers/MessageBuffer.cc,
> line 198]
>
> Do you think that the options I have specified should work correctly?
>
> Thanks
> Nilay
> ___
> m5-dev mailing list
> m5-dev@m5sim.org
> http://m5sim.org/mailman/listinfo/m5-dev
>



-- 
  Joel Hestness
  PhD Student, Computer Architecture
  Dept. of Computer Science, University of Texas - Austin
  http://www.cs.utexas.edu/~hestness
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

Re: [m5-dev] Review Request: Remove CacheMsg class from SLICC

2011-01-20 Thread Nilay Vaish


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



src/mem/ruby/system/Sequencer.cc


This is the portion of code that is not working correctly. If I compile 
this code, it works correctly with ruby random tester. But if I were to 
un-comment this line and comment out the one below, the code exits due to 
segmentation fault. In the debug mode, the code fails one of the assertion on 
the request type.


- Nilay


On 2011-01-20 14:06:16, Nilay Vaish wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/327/
> ---
> 
> (Updated 2011-01-20 14:06:16)
> 
> 
> Review request for Default.
> 
> 
> Summary
> ---
> 
> 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 libruby.hh. In fact, objects of class 
> CacheMsg are generated by copying values from a RubyRequest object.
> 
> This is not complete as of yet. I am facing some difficulty in handling the 
> RefCountingPtr. To me it seems that I am creating the reference correctly. 
> So, the object gets deleted before all the references have gone out of scope.
> 
> 
> Diffs
> -
> 
>   src/cpu/testers/rubytest/RubyTester.hh UNKNOWN 
>   src/mem/protocol/MOESI_hammer-cache.sm UNKNOWN 
>   src/mem/protocol/RubySlicc_Exports.sm UNKNOWN 
>   src/mem/protocol/RubySlicc_Profiler.sm UNKNOWN 
>   src/mem/protocol/RubySlicc_Types.sm UNKNOWN 
>   src/mem/ruby/SConscript UNKNOWN 
>   src/mem/ruby/common/Address.hh UNKNOWN 
>   src/mem/ruby/common/Address.cc UNKNOWN 
>   src/mem/ruby/common/DataBlock.hh UNKNOWN 
>   src/mem/ruby/common/DataBlock.cc UNKNOWN 
>   src/mem/ruby/filters/BlockBloomFilter.cc UNKNOWN 
>   src/mem/ruby/filters/BulkBloomFilter.cc UNKNOWN 
>   src/mem/ruby/filters/LSB_CountingBloomFilter.cc UNKNOWN 
>   src/mem/ruby/filters/MultiGrainBloomFilter.cc UNKNOWN 
>   src/mem/ruby/filters/NonCountingBloomFilter.cc UNKNOWN 
>   src/mem/ruby/libruby.hh UNKNOWN 
>   src/mem/ruby/libruby.cc UNKNOWN 
>   src/mem/ruby/libruby_internal.hh UNKNOWN 
>   src/mem/ruby/profiler/AccessTraceForAddress.cc UNKNOWN 
>   src/mem/ruby/profiler/AddressProfiler.hh UNKNOWN 
>   src/mem/ruby/profiler/AddressProfiler.cc UNKNOWN 
>   src/mem/ruby/profiler/Profiler.hh UNKNOWN 
>   src/mem/ruby/profiler/Profiler.cc UNKNOWN 
>   src/mem/ruby/recorder/CacheRecorder.hh UNKNOWN 
>   src/mem/ruby/recorder/CacheRecorder.cc UNKNOWN 
>   src/mem/ruby/recorder/TraceRecord.hh UNKNOWN 
>   src/mem/ruby/recorder/TraceRecord.cc UNKNOWN 
>   src/mem/ruby/recorder/Tracer.hh UNKNOWN 
>   src/mem/ruby/recorder/Tracer.cc UNKNOWN 
>   src/mem/ruby/slicc_interface/RubyRequest.hh PRE-CREATION 
>   src/mem/ruby/slicc_interface/RubySlicc_Profiler_interface.hh UNKNOWN 
>   src/mem/ruby/slicc_interface/RubySlicc_Util.hh UNKNOWN 
>   src/mem/ruby/slicc_interface/SConscript UNKNOWN 
>   src/mem/ruby/storebuffer/stb_interface.cc UNKNOWN 
>   src/mem/ruby/storebuffer/storebuffer.cc UNKNOWN 
>   src/mem/ruby/system/CacheMemory.hh UNKNOWN 
>   src/mem/ruby/system/CacheMemory.cc UNKNOWN 
>   src/mem/ruby/system/DMASequencer.hh UNKNOWN 
>   src/mem/ruby/system/DMASequencer.cc UNKNOWN 
>   src/mem/ruby/system/PerfectCacheMemory.hh UNKNOWN 
>   src/mem/ruby/system/RubyPort.hh UNKNOWN 
>   src/mem/ruby/system/RubyPort.cc UNKNOWN 
>   src/mem/ruby/system/Sequencer.hh UNKNOWN 
>   src/mem/ruby/system/Sequencer.cc UNKNOWN 
>   src/mem/ruby/system/SparseMemory.cc UNKNOWN 
>   src/mem/slicc/parser.py UNKNOWN 
> 
> Diff: http://reviews.m5sim.org/r/327/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Nilay
> 
>

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

[m5-dev] Review Request: Remove CacheMsg class from SLICC

2011-01-20 Thread Nilay Vaish


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

Review request for Default.


Summary
---

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 libruby.hh. In fact, objects of class CacheMsg 
are generated by copying values from a RubyRequest object.

This is not complete as of yet. I am facing some difficulty in handling the 
RefCountingPtr. To me it seems that I am creating the reference correctly. So, 
the object gets deleted before all the references have gone out of scope.


Diffs
-

  src/cpu/testers/rubytest/RubyTester.hh UNKNOWN 
  src/mem/protocol/MOESI_hammer-cache.sm UNKNOWN 
  src/mem/protocol/RubySlicc_Exports.sm UNKNOWN 
  src/mem/protocol/RubySlicc_Profiler.sm UNKNOWN 
  src/mem/protocol/RubySlicc_Types.sm UNKNOWN 
  src/mem/ruby/SConscript UNKNOWN 
  src/mem/ruby/common/Address.hh UNKNOWN 
  src/mem/ruby/common/Address.cc UNKNOWN 
  src/mem/ruby/common/DataBlock.hh UNKNOWN 
  src/mem/ruby/common/DataBlock.cc UNKNOWN 
  src/mem/ruby/filters/BlockBloomFilter.cc UNKNOWN 
  src/mem/ruby/filters/BulkBloomFilter.cc UNKNOWN 
  src/mem/ruby/filters/LSB_CountingBloomFilter.cc UNKNOWN 
  src/mem/ruby/filters/MultiGrainBloomFilter.cc UNKNOWN 
  src/mem/ruby/filters/NonCountingBloomFilter.cc UNKNOWN 
  src/mem/ruby/libruby.hh UNKNOWN 
  src/mem/ruby/libruby.cc UNKNOWN 
  src/mem/ruby/libruby_internal.hh UNKNOWN 
  src/mem/ruby/profiler/AccessTraceForAddress.cc UNKNOWN 
  src/mem/ruby/profiler/AddressProfiler.hh UNKNOWN 
  src/mem/ruby/profiler/AddressProfiler.cc UNKNOWN 
  src/mem/ruby/profiler/Profiler.hh UNKNOWN 
  src/mem/ruby/profiler/Profiler.cc UNKNOWN 
  src/mem/ruby/recorder/CacheRecorder.hh UNKNOWN 
  src/mem/ruby/recorder/CacheRecorder.cc UNKNOWN 
  src/mem/ruby/recorder/TraceRecord.hh UNKNOWN 
  src/mem/ruby/recorder/TraceRecord.cc UNKNOWN 
  src/mem/ruby/recorder/Tracer.hh UNKNOWN 
  src/mem/ruby/recorder/Tracer.cc UNKNOWN 
  src/mem/ruby/slicc_interface/RubyRequest.hh PRE-CREATION 
  src/mem/ruby/slicc_interface/RubySlicc_Profiler_interface.hh UNKNOWN 
  src/mem/ruby/slicc_interface/RubySlicc_Util.hh UNKNOWN 
  src/mem/ruby/slicc_interface/SConscript UNKNOWN 
  src/mem/ruby/storebuffer/stb_interface.cc UNKNOWN 
  src/mem/ruby/storebuffer/storebuffer.cc UNKNOWN 
  src/mem/ruby/system/CacheMemory.hh UNKNOWN 
  src/mem/ruby/system/CacheMemory.cc UNKNOWN 
  src/mem/ruby/system/DMASequencer.hh UNKNOWN 
  src/mem/ruby/system/DMASequencer.cc UNKNOWN 
  src/mem/ruby/system/PerfectCacheMemory.hh UNKNOWN 
  src/mem/ruby/system/RubyPort.hh UNKNOWN 
  src/mem/ruby/system/RubyPort.cc UNKNOWN 
  src/mem/ruby/system/Sequencer.hh UNKNOWN 
  src/mem/ruby/system/Sequencer.cc UNKNOWN 
  src/mem/ruby/system/SparseMemory.cc UNKNOWN 
  src/mem/slicc/parser.py UNKNOWN 

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


Testing
---


Thanks,

Nilay

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

[m5-dev] Notification from M5 Bugs

2011-01-20 Thread Flyspray

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.

The following task has a new comment added:

FS#337 - Checkpoint Tester Identifies Mismatches (Bugs) for X86_FS
User who did this: - Brad Beckmann (beckmabd)

--
Oops...it is the same command line, just a different binary:

util/checkpoint-tester.py -i 2000 --
build/X86_FS_MOESI_hammer/m5.debug configs/example/fs.py --script
test/halt.sh
--

More information can be found at the following URL:
http://www.m5sim.org/flyspray/task/337#comment162

You are receiving this message because you have requested it from the
Flyspray bugtracking system.  You can be removed from future
notifications by visiting the URL shown above.

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

[m5-dev] 3 Bugs in the checkpoint_restore for spec2006

2011-01-20 Thread Richard Strong

Hi all,

I uncovered 3 bugs when trying to resume in ALPHA_SE from a checkpoint for
the spec2006 benchmarks. They are:

(1) Unserializing curTick failed because the checkpoint file wrote
curTick()=, but the unserializing code was expecting curTick=

(2) The mode bit was not being stored in the file descriptor checkpoint. I
added a feature to store the mode bit.

(3) The dup function was duplicating the wrong file descriptor.

Let me know what you think, I give the diff below along with a traceflag
that allowed me to find the problem.

Best,
-Rick

diff --git a/src/sim/SConscript b/src/sim/SConscript
--- a/src/sim/SConscript
+++ b/src/sim/SConscript
@@ -77,3 +77,4 @@
 TraceFlag('Thread')
 TraceFlag('Timer')
 TraceFlag('VtoPhys')
+TraceFlag('FileDescriptors')
diff --git a/src/sim/process.cc b/src/sim/process.cc
--- a/src/sim/process.cc
+++ b/src/sim/process.cc
@@ -268,6 +268,7 @@
 int
 Process::alloc_fd(int sim_fd, string filename, int flags, int mode, bool
pipe)
 {
+DPRINTF(FileDescriptors, "alloc_fd fd:%d filename:%s\n", sim_fd,
filename);
 // in case open() returns an error, don't allocate a new fd
 if (sim_fd == -1)
 return -1;
@@ -295,6 +296,7 @@
 void
 Process::free_fd(int tgt_fd)
 {
+DPRINTF(FileDescriptors, "free_fd fd:%d name:%s\n", tgt_fd, "NULL");
 Process::FdMap *fdo = &fd_map[tgt_fd];
 if (fdo->fd == -1)
 warn("Process::free_fd: request to free unused fd %d", tgt_fd);
@@ -324,8 +326,16 @@
 {
 if (tgt_fd > MAX_FD)
 panic("sim_fd_obj called in fd out of range.");
+

-return &fd_map[tgt_fd];
+//return &fd_map[tgt_fd];
+for (int x = 0; x <= MAX_FD; x++) {
+   if (fd_map[x].fd == tgt_fd){
+   return &fd_map[x];
+   }
+ }
+ panic("sim_fd_obj could not find system fd.");
+ return NULL;
 }

 bool
@@ -458,6 +468,7 @@
 if (fdo->fd != -1) {
 fdo->fileOffset = lseek(fdo->fd, 0, SEEK_CUR);
 } else {
+DPRINTF(FileDescriptors, "find_file_offsets fd:%d
filename:%s\n", fdo->fd, fdo->filename);
 fdo->filename = "NULL";
 fdo->fileOffset = 0;
 }
@@ -480,6 +491,7 @@
 SERIALIZE_SCALAR(flags);
 SERIALIZE_SCALAR(readPipeSource);
 SERIALIZE_SCALAR(fileOffset);
+SERIALIZE_SCALAR(mode);
 }

 void
@@ -491,6 +503,7 @@
 UNSERIALIZE_SCALAR(flags);
 UNSERIALIZE_SCALAR(readPipeSource);
 UNSERIALIZE_SCALAR(fileOffset);
+UNSERIALIZE_SCALAR(mode);
 }

 void
diff --git a/src/sim/serialize.cc b/src/sim/serialize.cc
--- a/src/sim/serialize.cc
+++ b/src/sim/serialize.cc
@@ -411,7 +411,7 @@
 {
 const string §ion = name();
 Tick tick;
-paramIn(cp, section, "curTick", tick);
+paramIn(cp, section, "curTick()", tick);
 curTick(tick);

 mainEventQueue.unserialize(cp, "MainEventQueue");
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

[m5-dev] Notification from M5 Bugs

2011-01-20 Thread Flyspray

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.

The following task has a new comment added:

FS#337 - Checkpoint Tester Identifies Mismatches (Bugs) for X86_FS
User who did this: - Gabe Black (gblack)

--
Your command line to reproduce the problem looks like it's for
ALPHA_FS, not X86_FS. Could you please provide the one you used for
X86?
--

More information can be found at the following URL:
http://www.m5sim.org/flyspray/task/337#comment161

You are receiving this message because you have requested it from the
Flyspray bugtracking system.  You can be removed from future
notifications by visiting the URL shown above.

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

Re: [m5-dev] RefCountingPtr

2011-01-20 Thread nathan binkert

> So how would you handle pointer to an object which is reference counted?
> Pointer to the same object may be being used at multiple places.

That's what the RefCountingPtr class is all about.  It is a "smart
pointer" and automatically increments and decrements the reference
counts on the object.

> I am facing some trouble with this. Should I post the code on the review
> board?
Sure.

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

Re: [m5-dev] RefCountingPtr

2011-01-20 Thread Nilay Vaish

So how would you handle pointer to an object which is reference counted? 
Pointer to the same object may be being used at multiple places.


I am facing some trouble with this. Should I post the code on the review 
board?


Nilay

On Thu, 20 Jan 2011, nathan binkert wrote:


What's the need of having reference counting? And more specifically, why do
we need message going into ruby to be reference counted?


Reference counting is a garbage collection strategy.  It also happens
to be one that is easily used in C++.  The specific reason why we use
reference counting in a few places is because it can some times be
difficult to keep track of an object and know when to delete it.  For
example, if you fire off a message into the memory system, who is
responsible for deleting it?  There are many different paths that a
message could take and potentially many different endpoints where a
message could be finished.  With reference counting, when the last
reference is given up, the object is automatically destroyed.  For
more info, I suggest wikipedia or google.

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

2011-01-20 Thread nathan binkert

> What's the need of having reference counting? And more specifically, why do
> we need message going into ruby to be reference counted?

Reference counting is a garbage collection strategy.  It also happens
to be one that is easily used in C++.  The specific reason why we use
reference counting in a few places is because it can some times be
difficult to keep track of an object and know when to delete it.  For
example, if you fire off a message into the memory system, who is
responsible for deleting it?  There are many different paths that a
message could take and potentially many different endpoints where a
message could be finished.  With reference counting, when the last
reference is given up, the object is automatically destroyed.  For
more info, I suggest wikipedia or google.

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

[m5-dev] RefCountingPtr

2011-01-20 Thread Nilay Vaish

What's the need of having reference counting? And more specifically, why 
do we need message going into ruby to be reference counted?


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

[m5-dev] Error in Simulating Mesh Network

2011-01-20 Thread Nilay Vaish


Brad, I tried simulating a mesh network with four processors.

./build/ALPHA_FS_MOESI_hammer/m5.prof ./configs/example/ruby_fs.py 
--maxtick 2000 -n 4 --topology Mesh --mesh-rows 2 --num-l2cache 4 
--num-dir 4


I receive the following error:

panic: FIFO ordering violated: [MessageBuffer:  consumer-yes [ [71227521, 
870, 1; ] ]] [Version 1, L1Cache, triggerQueue_in]
 name: [Version 1, L1Cache, triggerQueue_in] current time: 71227512 delta: 
1 arrival_time: 71227513 last arrival_time: 71227521

 @ cycle 35613756000
[enqueue:build/ALPHA_FS_MOESI_hammer/mem/ruby/buffers/MessageBuffer.cc, 
line 198]


Do you think that the options I have specified should work correctly?

Thanks
Nilay
___
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-01-20 Thread Cron Daemon

* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby 
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/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/00.hello/alpha/linux/simple-timing-ruby 
passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-timing passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/o3-timing passed.
* build/ALPHA_SE/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby 
passed.
* build/ALPHA_SE/tests/fast/quick/01.hello-2T-smt/alpha/linux/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/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/o3-timing passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/inorder-timing 
passed.
* build/ALPHA_SE/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby 
passed.
* 
build/ALPHA_SE_MOESI_hammer/tests/fast/quick/60.rubytest/alpha/linux/rubytest-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/00.hello/alpha/linux/simple-timing-ruby-MOESI_hammer
 passed.
* build/ALPHA_SE/tests/fast/quick/50.memtest/alpha/linux/memtest passed.
* 
build/ALPHA_SE_MOESI_hammer/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby-MOESI_hammer
 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/60.rubytest/alpha/linux/rubytest-ruby-MESI_CMP_directory
 passed.
* 
build/ALPHA_SE_MESI_CMP_directory/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MESI_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_directory/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_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_MESI_CMP_directory/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby-MESI_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_token/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_token
 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/60.rubytest/alpha/linux/rubytest-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_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.
= Statistics differences =* 
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/simple-timing-ruby 
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-atomic passed.
* build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/o3-timing passed.
* build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/inorder-timing 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/02.insttest/sparc/linux/simple-atomic 
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/40.m5threads-test-atomic/sparc/linux/simple-timing-mp
 passed.
* build/SPARC_SE/tests/fast/quick/00.hello/sparc/linux/simple-atomic passed.
* 
build/SPARC_SE/tests/fast/quick/40.m5threads-test-atomic/sparc/linux/o3-timing-mp
 passed.
* build/SPARC_SE/tests/fast/quick/02.instt

Re: [m5-dev] changeset in m5: checkpointing: fix bug from curTick accessor co...

Re: [m5-dev] 3 Bugs in the checkpoint_restore for spec2006

[m5-dev] changeset in m5: checkpointing: fix bug from curTick accessor co...

Re: [m5-dev] 3 Bugs in the checkpoint_restore for spec2006

Re: [m5-dev] Review Request: x86: Timing support for pagetable walker

Re: [m5-dev] Review Request: x86: implements vtophys

Re: [m5-dev] Error in Simulating Mesh Network

Re: [m5-dev] Review Request: Remove CacheMsg class from SLICC

Re: [m5-dev] Error in Simulating Mesh Network

Re: [m5-dev] Review Request: Remove CacheMsg class from SLICC

[m5-dev] Review Request: Remove CacheMsg class from SLICC

[m5-dev] Notification from M5 Bugs

[m5-dev] 3 Bugs in the checkpoint_restore for spec2006

[m5-dev] Notification from M5 Bugs

Re: [m5-dev] RefCountingPtr

Re: [m5-dev] RefCountingPtr

Re: [m5-dev] RefCountingPtr

[m5-dev] RefCountingPtr

[m5-dev] Error in Simulating Mesh Network

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

20 matches

Site Navigation

Mail list logo

Footer information