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
