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
