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
