----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/1386/#review3515 -----------------------------------------------------------
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/#comment3536> unsigned int? src/mem/ruby/system/Sequencer.cc <http://reviews.gem5.org/r/1386/#comment3537> Why the == false instead of adding a ! at the start of the line? - Andreas Hansson On Sept. 21, 2012, 9:08 p.m., Joel Hestness wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/1386/ > ----------------------------------------------------------- > > (Updated Sept. 21, 2012, 9:08 p.m.) > > > Review request for Default. > > > 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. > > > Diffs > ----- > > src/mem/ruby/system/RubyPort.hh c208c904ab13 > src/mem/ruby/system/RubyPort.cc c208c904ab13 > src/mem/ruby/system/Sequencer.cc c208c904ab13 > > 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
