Seems like the non-spec, mem. barrier inst has a fault. Can you identify what fault it is (inst->getFault()->name())?
Also, what's the "Commit" debug flag trace say on the tick where the CPU decides it can't commit that particular instruction? On Mon, Oct 31, 2011 at 1:13 PM, Nilay Vaish <[email protected]> wrote: > Hello > > I am observing a peculiar behavior while running the O3 CPU. There is a > non-speculative, memory barrier instruction at the head of the ROB. The ROB > waits for many ticks to write back all the stores before this instruction. > Then all of a sudden, in of the ticks, the CPU decides that it cannot > commit this particular instruction and then it decides to squash this > instruction. Can some one explain as to why this might happen? > > While squashing the instruction, the following code from the function > doSquash() in o3/inst_queue_impl.hh is invoked. That particular instruction > fails on the assert. If I comment out the assert, the simulation runs to > completion (which is indicator of nothing). Should this instruction fail > this assert? How can I ensure that the simulation runs fine even when the > assert is in place? > > > } else if (!squashed_inst->**isStoreConditional() || > !squashed_inst->isCompleted()) { > NonSpecMapIt ns_inst_it = > nonSpecInsts.find(squashed_**inst->seqNum); > > if (ns_inst_it == nonSpecInsts.end()) { > assert(squashed_inst->**getFault() != NoFault); > } else { > > (*ns_inst_it).second = NULL; > > nonSpecInsts.erase(ns_inst_it)**; > > ++iqSquashedNonSpecRemoved; > } > } > > Note that I am running O3 CPU with Ruby. > > Thanks > Nilay > ______________________________**_________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/**listinfo/gem5-dev<http://m5sim.org/mailman/listinfo/gem5-dev> > -- - Korey _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
