----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/1386/#review3372 -----------------------------------------------------------
src/mem/ruby/system/RubyPort.cc <http://reviews.gem5.org/r/1386/#comment3449> Why do you need to remove this local variable? Now you are calling outstandingCount() twice. src/mem/ruby/system/Sequencer.cc <http://reviews.gem5.org/r/1386/#comment3450> Are you sure this is correct? src/mem/ruby/system/Sequencer.cc <http://reviews.gem5.org/r/1386/#comment3451> I think there is one more place in Sequencer.cc where the deadlock event is scheduled. You might want to put the same check there as well. - Nilay Vaish On Aug. 31, 2012, 4:56 p.m., Joel Hestness wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/1386/ > ----------------------------------------------------------- > > (Updated Aug. 31, 2012, 4:56 p.m.) > > > Review request for Default. > > > Description > ------- > > Changeset 9185:97d6b8c92b6d > --------------------------- > RubyPort and Sequencer: Fix draining > > Fix the drain functionality of the RubyPort to only call drain on child ports > during a system-wide drain process, instead of calling each time that a > ruby_hit_callback is executed. > > This fixes the issue of the RubyPort ports being reawakened during the drain > simulation, possibly with work they didn't previously have to complete. If > they have new work, they may call process on the drain event that they had > not registered work for, causing an assertion failure in cleanupCountedDrain > (assert(event->getCount() == 0);) when completing the drain event. > > Also, in RubyPort, set the drainEvent to NULL when there are no events > to be drained. If not set to NULL, the drain loop can result in stale > drainEvents used. > > > Diffs > ----- > > src/mem/ruby/system/RubyPort.cc 42807286d6cb > src/mem/ruby/system/Sequencer.cc 42807286d6cb > > Diff: http://reviews.gem5.org/r/1386/diff/ > > > Testing > ------- > > Verified that all prior working Ruby checkpointing configurations still work > correctly. Verified that this fixes checkpoint restore into timing CPU and > then switch to detailed CPU with x86. Will need to verify that this works > when restoring in full-system simulation, functionality which is currently > obscured by another bug when restoring into detailed CPU in FS. > > > Thanks, > > Joel Hestness > > _______________________________________________ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
