I could not figure out what is the problem in the first place. All what I can
see is that the code behavior seems illogical because it will certainly cause
the assertion to fail consistently in timing mode
Regards
Mostafa
> Date: Thu, 10 Jan 2013 18:23:55 -0600
> From: ni...@cs.wisc.edu
> To: mostafa.m.has...@hotmail.com
> CC: gem5-users@gem5.org
> Subject: RE: [gem5-users] Running benchmark on FS X86 : Assertion
> `!delayedResponse' failed.
>
> What all did you try to solve this issue? Your initial reasoning for the
> problem was certainly incorrect.
>
> --
> Nilay
>
> On Fri, 11 Jan 2013, Mostafa Mahmoud Hassan wrote:
>
> >
> > Any guesses with this guys ?
> >
> > Regards
> > ------------------------------------------------------------------
> > why do you think that the walker inserted a translation then it was not
> > available when it comes to use it ?? could not it be the first time to look
> > for it and due to miss decided to perform a walk inserting it for the first
> > time ??
> >
> > I see from the code in tlb.cc (starting from line 292) that it failed to
> > lookup the address and decided to start a walk which (whatever the walk
> > caused a fault or not) will cause delayedResponse to change to true due to
> > the suspected behavior of this if condition "(timing || fault != NoFault)"
> > , as you can see this condition will always be true because we pass timing
> > = true on calling "translate" from WalkerState::recvPacket in
> > pagetable_walker.cc which blindly assert the "delayedResponse"
> >
> > ======================X86, TLB::translate ====================
> > if (m5Reg.paging) {
> > DPRINTF(TLB, "Paging enabled.\n");
> > &
> > nbsp; // The vaddr already has the segment base applied.
> > TlbEntry *entry = lookup(vaddr);
> > if (!entry) {
> > if (FullSystem) {
> > Fault fault = walker->start(tc, translation, req, mode);
> > if (timing || fault != NoFault) {
> > // This gets ignored in atomic mode.
> > &
> > nbsp; delayedResponse = true;
> > return fault;
> > }
> > entry = lookup(vaddr);
> > assert(entry);
> > } else {
> > DPRINTF(TLB, "Handling a TLB miss for "
> > &
> > nbsp; "address %#x at pc %#x.\n",
> > vaddr, tc->instAddr());
> >
> >
> > Compare this to the behavior in ARM architecture,
> >
> > ======================ARM, TLB::translateFs see lines
> > 516->541====================
> > fault = tableWalker->walk(req, tc, contextId, mode, translation,
> > timing, functional);
> > if (timing && fault == NoFault) {
> > delay = true;
> >
> > // for timing mode, return and wait for table walk
> > return fault;
> >
> > The condition here (timing && fault == NoFault) makes sense. In addition,
> > "delay" is properly checked in "TLB::translateTiming" function :
> > if (!delay)
> > translation->finish(fault, req, tc, mode);
> > else
> > translation->markDelayed();
> >
> >
> > Regards
> >
> >> It appears as though the page table walker inserted a translation into the
> >> TLB and then when it came to use that translation it wasn't available (and
> >> would >require another walk), which is causing the assert to happen. You
> >> should figure out what is being inserted and why it isn't matching in the
> >> tlb on the >walker->tlb->translate() call.>Ali
> >
> >
> >
> > _______________________________________________
> > 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
