* build/ALPHA_SE/tests/fast/quick/20.eio-short/alpha/eio/simple-timing
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.
*
If you look at the attached annotated trace you can see that a cache block was
written to, was dirty and then the dirty flag goes away at some point. I traced
it down to this code in the cache:
// special considerations if we're owner:
if
I am trying to push a couple of change sets, but I keep getting the
following response
remote: abort: No space left on device
abort: unexpected response: empty string
Can some one look into this?
--
Nilay
___
m5-dev mailing list
m5-dev@m5sim.org
I suggest you also add an assert in the fetch unit if it receives a block with
ownership, if that is easy to do.
Sent from my iPhone
On Feb 20, 2011, at 12:05 PM, Ali Saidi sa...@umich.edu wrote:
If you look at the attached annotated trace you can see that a cache block
was written to, was
Fixed...
Ali
On Feb 20, 2011, at 11:15 AM, Nilay Vaish wrote:
I am trying to push a couple of change sets, but I keep getting the following
response
remote: abort: No space left on device
abort: unexpected response: empty string
Can some one look into this?
--
Nilay
changeset 44f1ac4f587f in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=44f1ac4f587f
description:
Ruby: clean MOESI CMP directory protocol
The L1 cache controller file contains references to foo and goo queues,
which
are not in use at all. These have been
changeset 5e58eaf00b58 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=5e58eaf00b58
description:
Ruby: Machine Type missing in MOESI CMP directory protocol
In certain actions of the L1 cache controller, while creating an
outgoing
message, the machine
Yea, the protocol does assume that a full cache-block request is from
another coherent entity. Has O3 always fetched full cache blocks at a
time? If so, then I'm also surprised we haven't seen it (or maybe we have
seen it, but not recognized it).
Getting rid of this code would solve the
The fetch stage seems to have done that forever. I think because we're using
RAM as a filesystem for ARM at the moment that is one reason why it's more
prone to pop-up in this case, but it seems like it's been an issue for a long
time.
With my first suggestion the L2 could send the data up to
On Sun, Feb 20, 2011 at 8:34 PM, Ali Saidi sa...@umich.edu wrote:
The fetch stage seems to have done that forever. I think because we're
using RAM as a filesystem for ARM at the moment that is one reason why it's
more prone to pop-up in this case, but it seems like it's been an issue for
a
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/492/#review876
---
Looks like a good idea to me. Can any ruby people OK this for Korey?
-
11 matches
Mail list logo
