It seems there is no response waiting (or at least not ready). Is there any chance you could also add a deferredPacketReadyTime() to the DPRINTF just to find out if there is actually something waiting (and just not ready)?
Andreas -----Original Message----- From: gem5-users-boun...@gem5.org [mailto:gem5-users-boun...@gem5.org] On Behalf Of Nathanaël Prémillieu Sent: 11 June 2012 21:59 To: gem5-users@gem5.org Subject: Re: [gem5-users] Bpred: RAS maybe not getting correctly squashed (in some case) Here is a new trace with more output before and after: http://www.irisa.fr/alf/downloads/premillieu/gem5/445.gobmk.score2.trace_All-Event.gz The DPRINT statement is DPRINTF(Cache, "Got deferred packet ready\n"); Nathanaël Le 11/06/2012 18:33, Nathanaël Prémillieu a écrit : > I use the arm_detailed cpu model with no modification to the cpu > configuration. Here is the option I give to the se.py script: > --cpu-type=arm_detailed --caches --l2cache > --checkpoint-dir=/temp_dd/alf_2/npremill/spec2006/checkpoints/base/445.gobmk/cpt.gobmk.ref.score2 > --checkpoint-restore=200875000000 --at-instruction -m 1000000 -W > 25000000 --standard-switch -c > /local/npremill/test_gen3.445.gobmk.score2.14.2009/gobmk_base.armv7_nothumb-gcc > --input=score2.tst -o "--quiet --mode gtp" --output=score2.out > --errout=score2.err > > The only modification I have made to the se.py script is to have a > physical memory of 2048MB instead of 512MB. > > I have put the DPRINT statement in the code. I will send the trace > output once the run is done. > > Le 11/06/2012 18:06, Ali Saidi a écrit : >> Well, the good news is that it should'n be too hard to debug as it's >> just looping and not making any progress. The bad news is I can only >> make some guesses from the trace. It appears as though the L2 cache is >> blocked (out of MSHRs). At least some of these responses are coming from >> the L1 cache (responses to prefetcher requests that hit in the L1 >> icache). However, for reasons I'm not sure about the L1 seems to be >> sending a demand request and not the responses. That isn't supposed to >> happen. How many MSHRs does your L2 have? Can you put a DPRINT in the >> cache and see if you get into the deferredPacketReady if statement? >> >> if (deferredPacketReady()) { >> // use the normal approach from the timing port >> trySendTiming(); >> } else { >> >> >> >> Thanks, >> >> Ali >> >> >> >> On 11.06.2012 11:06, Nathanaël Prémillieu wrote: >> >>> The trace continues with the same lines again and again. I have waited >>> for the simulator to finish for more than one day but it is in this >>> infinite loop retrying to do the access. >>> >>> Nathanaël >> >> >> _______________________________________________ >> gem5-users mailing list >> gem5-users@gem5.org >> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users > _______________________________________________ > gem5-users mailing list > gem5-users@gem5.org > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users _______________________________________________ gem5-users mailing list gem5-users@gem5.org 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. _______________________________________________ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
