Ruby is made and the quality of the patches.
>
> Thanks,
> Ali
>
> On May 1, 2009, at 6:52 PM, Rick Strong wrote:
>
>
>> Hi all,
>>
>> I am finishing tests with Jiayuan's directory coherence patch. I
>> have it
>> working with the MemTest
ed state in two
> different caches?
>
> Ali
>
> On May 1, 2009, at 1:14 AM, Rick Strong wrote:
>
>
>> Hi all,
>>
>> In the testing of directory coherence, I realized that
>> Cache::functionalAccess(PacketPtr pkt, CachePort
>> *incomingPort, Cach
y 1, 2009, at 6:49 PM, Rick Strong wrote:
>
>
>> Hi all,
>>
>>I created this tool that extended MemTest to work with L1 caches in
>> a fullsystem model. The idea is that you keep devices that forward
>> requests to and from the L1 cpu-side cache and it keeps
Hi all,
I am finishing tests with Jiayuan's directory coherence patch. I have it
working with the MemTest class, my memory Debugger for multiple levels,
mshr settings and applications in fullsys and syscall mode. I am now
putting it through its paces on parsec. It is up-to-date with m5-dev,
bu
Hi all,
I created this tool that extended MemTest to work with L1 caches in
a fullsystem model. The idea is that you keep devices that forward
requests to and from the L1 cpu-side cache and it keeps track of all
memory accesses with a funcmem blog that has zero latency. It also
schedules a
Hi all,
In the testing of directory coherence, I realized that
Cache::functionalAccess(PacketPtr pkt, CachePort
*incomingPort, CachePort *otherSidePort) had a problem. Let's say we
have a 3 level cache with each core with its own L1 and L2 but a shared
L3. L1A propagates a functional request,
wouldn't worry about that too much.
Thanks,
-Rick
>
> Lisa
>
> On Wed, Feb 4, 2009 at 5:09 PM, Rick Strong <mailto:rstr...@cs.ucsd.edu>> wrote:
>
> Lisa Hsu wrote:
> > Rick,
> >
> > 1) Just to follow up, did you figure out a good spee
IPC,
> you'd probably be in the right range.
>
> Lisa
>
>
> On Wed, Jan 28, 2009 at 8:26 PM, Rick Strong <mailto:rstr...@cs.ucsd.edu>> wrote:
>
> The clock rate on the server is only set to 1GHz on the
> checkpoint run
>
nd trip latency.
> You should add some latency to the ethernet link, and drive the server
> with a slower CPU during the checkpoint run. That will normally fix
> the problem.
>
> Ali
>
>
>
>
> On Jan 28, 2009, at 5:59 PM, Rick Strong wrote:
>
>
>>
.umich.edu/%7Ehsul/pubs/mobs05.pdf>
>
> Just throwing that out as a possibility. You might want to "slow
> down" your checkpoint dropping run so that it's not so disruptive when
> you switch over to timing.
>
> Lisa
>
> On Wed, Jan 28, 2009 at 5:32 PM, Rick
de and and nothing seemed to
> jump out at me. If you can provide me with an EthernetAll trace from
> the checkpoint run and from the restored run I can work on figuring
> out what the problem is.
>
> Ali
>
>
>
> On Jan 28, 2009, at 2:53 AM, Rick Strong wrote:
>
he problem is.
>
All right. I will work on getting the two traces you suggest and see if
the differences become obvious.
Thanks,
-Rick
> Ali
>
>
>
> On Jan 28, 2009, at 2:53 AM, Rick Strong wrote:
>
>
>>> There are three possibilities here:
>>> a)
> There are three possibilities here:
> a) A kernel bug
> b) a device model/driver bug
> c) a checkpointing bug (as it relates to (b))
>
> What kernel version are you using? Could you put the ethernet trace
> somewhere so I could look at it?
>
> Ali
>
I am using the kernel 2.6.18 with M5 pa
Hi all and especially Ali,
I have been working with the webnew benchmark (specweb95-apache) and
have noticed two problems that kill throughput and was wondering if you
have encountered them or know what is happening
(1) All requests handled by the server server are coming back 404 (File)
Not F
(!IsOn(ExecMicro) && macroStaticInst && staticInst->isLastMicroop()))
>> {
>> traceInst(macroStaticInst, false);
>> }
>>
>> Anyways, please commit a fix asap, or else I'll just have to commit a
>> guess and put in a panic s
Hi all,
It appears that there is a compiler error in src/cpu/exetrace.cc for gcc
version 4.3.2 for m5dev.
scons: Building targets ...
g++ -o /home/rstrong/build/m5dev/build/ALPHA_SE/cpu/exetrace.do -c
-Wno-deprecated -pipe -fno-strict-aliasing -Wall -Wno-sign-compare
-Werror -Wundef -ggdb3 -D
I combined Gabe's changes with the patch you sent and it appears to work
now. I will cleanup the code and submit tonight.
Best,
-Rick
nathan binkert wrote:
> After hearing from Rick some more, I don't believe that this patch is
> sufficient. Rick? What about that patch I sent you?
>
> On Sun,
I accident committed with an email address that is not registered with
M5-Dev. I copied the message for your convenience.
Best,
-Rick
From: Richard Strong <[EMAIL PROTECTED]>
To: m5-dev@m5sim.org
Date: Tue, 09 Dec 2008 13:48:03 -0500
Subject: changeset in m5: IDE: Fix serialization for the IDE c
e scheduled on and in the future, there will be
> more than one event queue to choose from. I'll try to fix this for
> real as soon as I can.
>
> Nate
>
> On Tue, Oct 14, 2008 at 12:20 PM, Rick Strong <[EMAIL PROTECTED]> wrote:
>
>> Hi,
>>
>> I
Hi,
I am attempting to resume checkpoints in full system mode in scripts
that previously worked, but notice that the resume from checkpoint is
failing with:
panic: need to figure out how to unserialize scheduled events
Are checkpoints broken with the new eventq?
Best,
-Rick
not sure how it's supposed to work (perhaps only Korey can answer that),
>> but I think the basic problem here is that memAccFlags is only defined in
>> the Memory subclass of MipsStaticInst while what you are trying to
>> dereference is a pointer to the base Sta
Hi all,
So I am in process of getting the in-order model from mips to compile so
we can put it into the tree. I am having the following error:
Reading /Users/rickstrong/work/m5-dev/src/cpu/simple/SConsopts
scons: warning: The env.Copy() method is deprecated; use the env.Clone()
method instead.
That was the cause the assertion error in the quadcore experiments.
-Rick
nathan binkert wrote:
> I'm not saying that you're wrong, but can't this only be a problem if
> you specify a latency that's greater than 2 billion ticks (2us)? Were
> you running with this kind of super high latency?
>
>
Your second paragraph seems to be spot on. The problem was a redundant
delete of pkt->req in src/mem/tport.cc. Thanks for your intuition.
-Rick
Kevin Lim wrote:
> Hi Rick,
>
> Do you have any more information about what kind of object the
> RefCountingPtr is being used for? It's very open end
Hi all,
I am attempting to cleanup the cpu models in how they instantiate params
to look like the rest of the files in M5 (that is removing the Param
structures in AtomicSimpleCPU and BaseCPU to start ). I have worked
through many of the problems but I am wondering what is the best way to
cal
25 matches
Mail list logo