Ah, ok, yes, that makes sense. It's another example of more happening inside of a function than you expect, similar to the problem where a trace data structure was being freed and then later used way back on the stack. Things run farther and farther along until a delay is hit which may be quite a ways, and then finally fall back. People implicitly assume it won't actually go that far. Infinite fetch faults, for instance, like a fault while fetching a fault handler, would create infinite recursion and blow out the end of the stack. Ideally we'd periodically collapse the stack frame just because to avoid these sorts of issues.
Gabe Ali Saidi wrote: > completeIFetch() > -> initiateAcc() -- translation hits in TLB, page marked read only > so fault returned immediately > -> finishTranslation() is called by the DTLB and a fault has > been generated > -> translationFault() > -> advanceInst() > -> advancePC() > -> faultInvoke() > -> status == Running so then > advanceInst() calls fetch() > -> fetch() calls translateTiming() > for the fault handler because of the originating DTLB fault but status > doesn't change, so if it requires a table walk it's still running. If > it doesn't then it's fine > <- stack unwinds all the way to here now that we're waiting on fetch > -> advanceInst() -- since status still is Running > -> fetch() -- two instruction translates happen this cycle, > resulting in two translations and then two calls to sendFetch() > resulting in two data accesess > > Make sense? > > Ali > > > On Jan 19, 2011, at 4:45 AM, Gabe Black wrote: > >> This is an automatically generated e-mail. To reply, visit: >> http://reviews.m5sim.org/r/431/ >> >> >> I still don't understand how the CPU ends up in a bad state. Could you >> please list step by step how it happens? Use little words and go slowly :-). >> >> - Gabe >> >> >> On January 18th, 2011, 2:34 p.m., Ali Saidi wrote: >> >> Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, >> and Nathan Binkert. >> By Ali Saidi. >> >> /Updated 2011-01-18 14:34:11/ >> >> >> Description >> >> SimpleCPU: Fix a case where a DTLB fault redirects fetch and an I-side walk >> occurs. >> >> This change fixes an issue where a DTLB fault occurs and redirects fetch to >> handle the fault and the ITLB requires a walk which delays translation. In >> this >> case the status of the cpu isn't updated appropriately, and an additional >> instruction fetch occurs. Eventually this hits an assert as multiple >> instruction >> fetches are occuring in the system and when the second one returns the >> processor is in the wrong state. >> >> Some asserts below are removed because it was always true (typo) and the >> state >> after the initiateAcc() the processor could be in any valid state when a >> d-side fault occurs. >> >> >> Diffs >> >> * src/cpu/simple/timing.hh (32b6354d2ae6) >> * src/cpu/simple/timing.cc (32b6354d2ae6) >> >> View Diff <http://reviews.m5sim.org/r/431/diff/> >> >> _______________________________________________ >> m5-dev mailing list >> m5-dev@m5sim.org <mailto:m5-dev@m5sim.org> >> http://m5sim.org/mailman/listinfo/m5-dev > > ------------------------------------------------------------------------ > > _______________________________________________ > m5-dev mailing list > m5-dev@m5sim.org > http://m5sim.org/mailman/listinfo/m5-dev > _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
