* 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.
*
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:
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
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
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
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
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:
---
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
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/327/#review790
---
src/mem/ruby/system/Sequencer.cc
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 ni...@cs.wisc.edu wrote:
Brad, I
---
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
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.
---
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
---
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
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
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
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
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
18 matches
Mail list logo
