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
