It probably means that gem5 started, but didn't finish for some reason.
You should have log files somewhere in the build directory (you'll see
the paths if you re-run the regressions) that tells you what went wrong.
Some of the regressions will fail if you don't have the right SPEC2000
binaries in a magic structure in your m5 directory. However, the
switcheroo test should run if you have the kernel and disk images from
the gem5 web page.
Also, try running your switching test with the default detailed
configuratin as well as your configuration. There might be hidden
assumptions in the O3 model that break when you change the configuration.
//Andreas
On 2014-02-04 01:51, Srinivasan Narayanamoorthy wrote:
Hi Andreas,It is failing in both my version as well as an unmodified version of
gem5.
"gem5 exited with non-zero status 1" . Has the test even started if this is the
error message?
Thanks
Srini
On 02/03/14, Andreas Sandberg wrote:
Hi Srini,
Could you provide some more details about your experiments? Which architecture
are you simulating and which CPU models are you using?
Also, which version of gem5 are you using? Preferably, which commit are you on?
Could you try to run the regressions tests on the simulator? Particularly the
switcheroo tests.
I've been running several experiments where I've been 10s of thousands of
switches between kvm/atomic/o3, which worked fine on a version from ~November
last year. There are a couple of known regressions that were introduced around
November that might be biting you. If you are using KVM, you need to use a
version from last Sunday or newer, otherwise rflags synchronization on x86
won't work because of a regression introduced a couple of months ago.
//Andreas
On 2014-02-03 22:13, Srinivasan Narayanamoorthy wrote:
Hi,I am Srini. I am kind of a new user to gem5 and for some of my experiments,
I need to repeatedly switch between two cpu models. I figured configuring
repeat-switch option is an easy way of doing it but was soon hitting some drain
related assertions. Turns out that when the drain manager is signaled
drainDone, decode/rename could be unblocking/blocked and the unblocking status
is not propagated to fetch(1 cycle delay), and hence fails the drainSanityCheck
happening in the same cycle.
So to avoid this , I qualified the isDrained() in each of the stages with the
corresponding status signals and those assertions are not firing. I also
emptied the branch history on a drain. Please let me know if what I am doing is
correct.
Thanks
Srini
_______________________________________________
gem5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
