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
> 
> _______________________________________________
> 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

Reply via email to