On Tue, Sep 21, 2010 at 7:59 PM, nathan binkert n...@binkert.org wrote:
I see that objects/__init__.py does a from m5.internal import
params, so object.params still works; if we just change
internal/params.py to import all the modules that start with either
param_ or enum_ and get rid of the
I would guess that the issues aren't related, but it's always difficult to
be certain. Have you tried running it with valgrind?
Valgrind shows an initialization error and what appears to be an
interesting memcpy bug in packet handling in the cache tags, but it doesn't
look like either are the
Well, there are several issues there that we need to fix. I just saw the
source/dest bug as well. Steve, any idea under what conditions this happens? I
couldn't quite trace through the code and I don't understand why the packet
that is attached to the mshr and the received packet should have
That memcpy issue is funky but it appears innocuous... note that the
src and dest are identical (not just overlapping) so it's really a
no-op. Looking at the code more closely, it appears to happen here:
if (mshr-isForward) {
// not a cache block request, but a response is
We could also just protect the case if (addr1 != addr2) I've thown that in
to make the error go away so I can get on with other errors... another two to
add to the list:
==5949== Conditional jump or move depends on uninitialised value(s)
==5949==at 0x9BB623:
From memcpy's man page:
DESCRIPTION
The memcpy() function copies n bytes from memory area src to
memory area dest. The memory areas should not
overlap. Use memmove(3) if the memory areas do overlap.
So I think to play nice, we shouldn't copy even from a buffer to itself.
I don't
On Sun, Sep 19, 2010 at 1:39 AM, Ali Saidi sa...@umich.edu wrote:
On Sep 17, 2010, at 10:10 PM, Joel Hestness wrote:
Try simply internal.enums.timing, that should work.
To use this, I had to also add 'import enums' to
src/python/m5/internal/__init__.py. It looks like this completely fixed
On Sun, Sep 19, 2010 at 6:35 AM, nathan binkert n...@binkert.org wrote:
Is it possible that these issues are related?
I would guess that the issues aren't related, but it's always difficult to
be certain. Have you tried running it with valgrind? It might turn up
something easy. This,
Try simply internal.enums.timing, that should work.
To use this, I had to also add 'import enums' to
src/python/m5/internal/__init__.py. It looks like this completely fixed the
restore problem for the Atomic and Timing CPUs.
When I tried to restore into the O3 CPU, M5 entered simulation, but
Hi guys,
I am using swig 1.3.40, so per Nate's note in the last changeset, I don't
think that should be an issue.
@Steve: Thanks for the pointer to 'bisect'. Also, in debugging this
problem, I ran into the same MC146818 checkpointing/drain bug from before.
Previously, I had written a patch to
On Thu, Sep 16, 2010 at 4:12 PM, Joel Hestness hestn...@cs.utexas.edu wrote:
Hi guys,
I am using swig 1.3.40, so per Nate's note in the last changeset, I don't
think that should be an issue.
@Steve: Thanks for the pointer to 'bisect'. Also, in debugging this
problem, I ran into the same
if system.getMemoryMode() != objects.params.timing:
AttributeError: 'module' object has no attribute 'timing'
I'm pretty sure that this is my fault. Can you change it to
internal.params.timing and let me know if it works?
Thanks,
Nate
___
Hi,
I'm working on something else right now, and I might not have a chance to
dig into this for a while, so I figured I would post to the list:
I just updated to the most recent repo, and ALPHA checkpoint restore into
timing-enabled CPUs doesn't appear to be working:
1) Checkpoint by
13 matches
Mail list logo
