Cool. I fixed what Andreas listed below and tested this. Just pushed. Thanks, Joel
On Sun, Sep 23, 2012 at 6:03 AM, Andreas Hansson <andreas.hans...@arm.com>wrote: > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/1386/ > > Ship it! > > Overall this is fine with me. We have done some tinkering with the whole way > draining works, by removing the state and relying entirely on the counters in > a "tree" that reflects where there is still activity. This patch seems to > move in the same direction (but only for the RubyPort). > > > > src/mem/ruby/system/RubyPort.cc<http://reviews.gem5.org/r/1386/diff/3/?file=29833#file29833line597> > (Diff > revision 3) > > unsigned int > > 585 > > int child_drain_count = getChildDrainCount(de); > > unsigned int? > > > > src/mem/ruby/system/Sequencer.cc<http://reviews.gem5.org/r/1386/diff/3/?file=29834#file29834line212> > (Diff > revision 3) > > RequestStatus > > 210 > > if (deadlockCheckEvent.scheduled() == false) { > > 212 > > if (deadlockCheckEvent.scheduled() == false && > > Why the == false instead of adding a ! at the start of the line? > > > - Andreas > > On September 21st, 2012, 9:08 p.m., Joel Hestness wrote: > Review request for Default. > By Joel Hestness. > > *Updated Sept. 21, 2012, 9:08 p.m.* > Description > > Changeset 9228:0b63b7c87cde > --------------------------- > 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 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. > > 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. > > Diffs > > - src/mem/ruby/system/RubyPort.hh (c208c904ab13) > - src/mem/ruby/system/RubyPort.cc (c208c904ab13) > - src/mem/ruby/system/Sequencer.cc (c208c904ab13) > > View Diff <http://reviews.gem5.org/r/1386/diff/> > -- Joel Hestness PhD Student, Computer Architecture Dept. of Computer Science, University of Wisconsin - Madison http://www.cs.utexas.edu/~hestness _______________________________________________ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
