What about running scons inside the gem5 directory instead of your home
directory? And don't run it with sudo.
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s
Hi everyone,
I am looking to work on 2 computers with different versions of gem5. When I
have transferred the same executable from one PC to another and have tried the
execution with the same command, they have given me different values in the L1
cache. The command I ran was:
~/gem5/build/ARM/ge
Hi,
We are trying to do some simulations. We are using a simulator based on an old
version of Gem5 ([1] created to simulate a64fx chip).
We made some further modifications, namely replaced `SnoopMask` to be of type
`std::bitset<>` to be able to run more-or-less arbitrary number of cores. And
ru
Hi all,
Just to follow up, because I can see that there have been some issues with
not including all of the requisite issues in other threads, here is the
full output from what I described above.
gem5 Simulator System. http://gem5.org
gem5 is copyrighted software; use the --copyright option for
Hi Sam,
Sorry for the frustration. Writing better documentation is always #2 on the
priority list :(.
I always tell people not to trust any of the "options" to fs.py and se.py.
Those scripts have gotten so far beyond "out of hand" at this point that
they are almost useless. They are trying to be
Hi Emil,
You can remove that check. However, you should note that the classic caches
aren't designed to support high-bandwidth operation. Also, this assert
triggering could be a sign that there's infinite queuing somewhere (which
is one reason why the classic caches aren't great for high bandwidth
Hi Jason,
Thanks for your help. I think I've honed in on the source of the problem --
namely, number of cpus. Is there a reason why having multiple CPUs in a
particular configuration would limit the simulator's ability to write a
checkpoint?
Again, thank you for your help!
Best,
Sam
On Wed, Sep
Hi Sam,
I would *guess* it's the draining code getting stuck in an infinite loop.
The draining code calls "drain" on all SimObjects in the system, and they
do their thing. Then, the drain code asks all SimObjects if they're done
draining. If not, it starts over and calls drain on all objects again
Dear all,
The stable branch of the gem5 repository now contains the v21.1.0.1 hotfix
release. This release fixes a bug where the build output was being flooded
with "'deprecated' attribute directive ignored" warnings, as reported here:
https://gem5.atlassian.net/browse/GEM5-1063. While this bug ne
Sravani,
You have been posting very frequently to this mailing list asking for help
and, on at least two occasions, have ignored the feedback given to you.
While we want to help new gem5 users, we cannot hold your hand through
every problem. In case you are unaware, the gem5-users list is maintain
10 matches
Mail list logo