Hi,

I have implemented a fix that works for the case I was hitting. Review
request posted at http://reviews.gem5.org/r/1828/

-Gedare

On Wed, Apr 17, 2013 at 3:38 PM, Gedare Bloom <[email protected]> wrote:
> 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

Reply via email to