Hi Amin, 

That's curious that you're running into this issue
because we recently added a regression test (realview-switcheroo-full
and tsunami-switcheroo-full) that switch frequently between atomic,
timing, o3, atomic, timing, o3, ... and we don't encounter the error.
Any idea what is different between how the switching is done in those
cases and how you do the switching? 

Thanks, 

Ali 

On 25.01.2013
15:00, Amin Farmahini wrote: 

> Hi,
> 
> I have developed a model that
frequently switches between cpus. To be more
> specific, I switch
between O3 and a cpu model of mine. After new changes to
> O3 draining
(http://reviews.gem5.org/r/1568/ [1]), I have encountered two
>
assertion failures.
> 
> 1. assert(predHist[i].empty()); in
BPredUnit<Impl>::drainSanityCheck() (src
> /cpu/o3/bpred_unit_ipml.hh)
>
Prior to new patch, we squashed the history table before switching, but
as
> far as I understand, we don't do so any more in the new patch.
This
> assertion failure happens, for example, when you switch from
atomic to o3
> and then from o3 to atomic.
> 
> 2.
assert(!cpu->switchedOut()); in DefaultFetch<Impl>::
>
processCacheCompletion (src/cpu/o3/fetch_impl.hh)
> Obviously this
happens when fetch stage in O3 receives a packet from cache
> (possibly
after an Icache miss) while the o3 is switched out. Again,
> previously,
we used to detect such a situation and activate the fetch only
> if no
drain is pending.
> 
> I have found a solution to work around these
assertion failures, and I am
> not sure if this only happens to me
because of the specific way I use the
> O3 draining or not. I just
wanted to mention these assertion failures could
> be possible bugs.
>

> Thanks,
> Amin
> _______________________________________________
>
gem5-dev mailing list
> [email protected]
>
http://m5sim.org/mailman/listinfo/gem5-dev [2]

 

Links:
------
[1]
http://reviews.gem5.org/r/1568/
[2]
http://m5sim.org/mailman/listinfo/gem5-dev
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev

Reply via email to