Hi Andreas,Thanks for suggesting the solution. However, in this case, bus is still not drained. It is still processing previous I-cache requests. On a side note, I observed the following.
For decent sized fetch widths, we may quickly run out of MSHR's and the last fetch may result in a cacheBlock which in-turn sets fetch status to IcacheWaitRetry. Now when the first response comes back, the response packet may be deleted in processCacheCompletion(PacketPtr pkt). Is this expected behavior? Also in my case, I probably only need to increase the number of MSHR's ? I see that even the cache hit case gets blocked because of MSHR full. Please let me know how I should proceed here. Srini On 03/10/14, Andreas Hansson wrote: > Hi Srini, > > I have another suggestion, in the bus drain() we should not only check if > the state is IDLE, but also if waitingForPeer != NULL. I think that would > fix the problem. In essence the bus would then _not_ be considered drained > until the packet gets to retry and succeeds. > > It might be worth trying. How easy is it for you to reproduce the problem? > > Andreas > > On 3/10/14, 10:14 PM, "Srinivasan Narayanamoorthy" <[email protected]> > wrote: > > >Hi, > > > >I did some debugging and figured out whats happening. > > > > > >I cache request fails and fetch enters "IcacheRetryWait" state. (Debug > >message : Out of MSHR's) > >Now a drain comes along and the CPU starts the drain. > >However, while squashing fetch during drain, there is no check if a Retry > >packet is pending and hence the memReq is not set to null. > >In subsequent drainSanityCheck(), the assert(!memReq) hits. > > > > > >I could think of two solutions to solve this.. > >1) check for the IcacheRetryWait state in isDrained() before signalling > >drain. > >2) clear the memReq while squashing if state is IcacheRetryWait...I am > >not sure how to handle recvRetry() though in this case.. > > > > > >I am pretty sure that i might be missing something in either of the two > >solutions. I would be very thankful if a solution can be suggested. > > > > > >Thanks > >Srini > > > >On 03/10/14, Srinivasan Narayanamoorthy wrote: > >> Hi, > >> > >> I am trying to switch between two detailed ARM cpu models using > >>repeat-switch for bbench. I am hitting the assert(!memReq) assertion in > >>drainSanityCheck() after around around 3 seconds (300 switches) of > >>simulation time. I looked at the code but could not think of a situation > >>where drain would be signalled before a memReq is created. I am going to > >>look further but it would be very helpful if some one already has a > >>patch/solution to this. > >> > >> > >> My gem5 version is pretty recent from Jan 2014. The cores have DFS > >>implemented. I am avoiding other drainSanityCheck() assertions by adding > >>a condition to check if the stage is blocked before signalling drain. > >> > >> > >> 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 > > > > > -- IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. > > ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, > Registered in England & Wales, Company No: 2557590 > ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, > Registered in England & Wales, Company No: 2548782 > > _______________________________________________ > 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
