Based on studying (today) the x86 page walker code, it looks like I want to check for translations of squashed instructions in one of these places: 1) Walker::start(): check the head of currStates after queueing a new translation. 2) Walker::recvTimingResp(): check the current translation on each received packet.
Either approach would require fixing some of the state for any inflight packets for the translation and discarding any subsequent packets that are meant for the squashed translation. Do one of these approaches seem right, or am I off base? -Gedare On Tue, Apr 16, 2013 at 3:39 PM, Ali Saidi <[email protected]> wrote: > The issue with ARM was that the TLB was holding onto squashed instructions > for a long time trying to translate them. The fix was to squash the walks. > See http://repo.gem5.org/gem5/rev/baa17ba80e06 Something similar probably > needs to be done with x86. > > > > Ali > > > > > > > > On 16.04.2013 13:35, Jiachen Xue wrote: > > I am not using DRAMSim2. In my case, the assertion error happened because > dynamic instruction was not destroyed properly. As soon as the issue been > taken care of, the assertion error went away. > > > On Tue, Apr 16, 2013 at 3:05 PM, Gedare Bloom <[email protected]> wrote: >> >> I ran into this assertion with X86. I will try testing on the gem5 >> tip, but wonder if anyone has seen and solved this issue for x86. The >> other thread seems to have resulted in a fix for ARM >> (http://reviews.gem5.org/r/1402/). >> >> -Gedare >> >> On Fri, Apr 13, 2012 at 1:38 AM, Andrew Cebulski <[email protected]> wrote: >> > http://www.mail-archive.com/[email protected]/msg02810.html >> > >> > On Fri, Apr 13, 2012 at 1:31 AM, Jiachen Xue <[email protected]> wrote: >> >> >> >> Hi, >> >> >> >> I am working with X86 full system simulator using detailed cpu model. >> >> >> >> In my work, I need to modify the TLB structure and have to bring back >> >> some >> >> originally deferred memory accessing instructions >> >> back to work. >> >> >> >> During the simulation, I encountered the assertion error: >> >> cpu->instcount >> >> <= 1500 within src/cpu/base_dyn_inst_impl.hh : 130 >> >> >> >> Does anyone have a similar issue before? >> >> >> >> Thanks in advance, >> >> >> >> -- >> >> Sincerely, >> >> Jiachen Xue >> >> >> >> >> >> _______________________________________________ >> >> 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 >> _______________________________________________ >> gem5-users mailing list >> [email protected] >> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >> >> -- >> Sincerely, >> Jiachen Xue > > > _______________________________________________ > 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 _______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
