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
