Thanks Nilay! I was able to solve the problem without checkpointing MSHRs. It was due to an uninitialized array in the code which I added for checkpointing caches. And yes I think you are right about MSHRs not being associated with states in atomic mode.
I have other questions but I will save them for other threads. -Abhishek On Wed, Aug 3, 2011 at 11:16 AM, Nilay <[email protected]> wrote: > On Wed, August 3, 2011 9:39 am, Abhishek Rawat wrote: > > yeah even I thought so initially, but then it is trying to access > > MSHRQueues > > inside this function in cache_impl.hh: > > > > template<class TagStore> > > void > > Cache<TagStore>::functionalAccess(PacketPtr pkt, > > CachePort *incomingPort, > > CachePort *otherSidePort) > > > > > > > > Thanks, > > > > On Wed, Aug 3, 2011 at 10:12 AM, Nilay <[email protected]> wrote: > > > >> On Wed, August 3, 2011 8:28 am, Abhishek Rawat wrote: > >> > I figured out the reason for the problem. I wasn't serializing the > >> MSHR > >> > Queues which was causing the cpus to halt due to some corrupt state. I > >> am > >> > now trying to serialize MSHR queues. > >> > > >> > Thanks, > >> > Abhishek > >> > > >> > > >> > >> In atomic mode, I would not expect MSHRs to be in use as there would be > >> no > >> requests. > >> > > Even if the MSHRs are being accessed, I don't think that there is any > state associated with MSHRs at the time when the checkpoint is being > taken. > > -- > Nilay > > _______________________________________________ > gem5-users mailing list > [email protected] > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users > -- -Abhishek Graduate Student Computer Science University of Virginia --------------------------------------------------------------------------------------------------------------------- simplicity is the ultimate sophistication -Leonardo da Vinci
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
