Or another possibility (which I'm trying now because it seems cleanest) is to check in startWalk before doing any work.
-Gedare On Wed, Apr 17, 2013 at 3:10 PM, Gedare Bloom <[email protected]> wrote: > 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
