scons: *** Found dependency cycle(s):
*
build/ALPHA_SE_MOESI_CMP_directory/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_directory
passed.
*
build/ALPHA_SE_MESI_CMP_directory/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MESI_CMP_directory
passed.
*
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/328/#review839
---
Overall, this looks great. A pretty simple change that offers
Korey,
That idea of creating a fault was probably leading to a dead lock, as you
stated. Then, trying to stall the access as suggested, I added constraints
between stores in the Instruction Queue (actually inside MemDepUnit), where
only membar constraints were handled before. The simulator
On 2011-02-09 09:44:20, Brad Beckmann wrote:
src/mem/ruby/buffers/MessageBuffer.cc, line 234
http://reviews.m5sim.org/r/328/diff/2/?file=10257#file10257line234
Is there a reason why you want to pass the message pointer instead of
just the vnet id?
I would change that. It is a
One simple nitpick before you commit is to fix the commit message so you put
a proper summary line.
Nate
On Sat, Feb 5, 2011 at 12:47 PM, Nilay Vaish ni...@cs.wisc.edu wrote:
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/328/
Review request for
On Wed, 9 Feb 2011, nathan binkert wrote:
One simple nitpick before you commit is to fix the commit message so you put
a proper summary line.
Nate
What would you like it to be?
___
m5-dev mailing list
m5-dev@m5sim.org
One simple nitpick before you commit is to fix the commit message so you
put
a proper summary line.
Nate
What would you like it to be?
Whatever you want. Remember that it's supposed to be a single
descriptive word followed by a single line summary describing the
commit. It's described
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/327/#review841
---
Overall, this patch looks good to me as well. I just have a couple minor
Hello,
I first started using the Ruby Model in M5 about a week or so ago,
and was able to boot in FS mode (up to 64 cores once applying the
BigTsunami patches).
In order to keep up with the changes in the Ruby code, I have started
fetching recent updates from the devrepo.
However, in fetching
Thanks for letting us know. If it wouldn't be too much trouble, could
you please try some other changesets near the one that isn't working and
try to determine which one specifically broke things? A bunch of changes
went in recently so it would be helpful to narrow things down. I'm not
very
Hi Malek,
Yes, thanks for letting us know. I'm pretty sure I know what the problem is.
Previously, if a SC operation failed, the RubyPort would convert the request
packet to a response packet, bypassed writing the functional view of memory,
and pass it back up to the CPU. In my most recent
changeset d6294150a32e in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=d6294150a32e
description:
ruby: removed duplicate make response call
diffstat:
src/mem/ruby/system/RubyPort.cc | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diffs (11 lines):
diff -r
changeset 9aab11bcd84c in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=9aab11bcd84c
description:
Ext: Add X11 keysym header files to ext directory.
diffstat:
ext/x11keysym/keysym.h|76 +
ext/x11keysym/keysymdef.h | 2358
13 matches
Mail list logo
