> On Aug. 31, 2012, 7:35 p.m., Anthony Gutierrez wrote: > > Looking at the code it seems as though drain is only called on the child > > ports during a system-wide drain. It's true that testDrainComplete() is > > called every time ruby_hit_callback() is called, but, if the drainEvent is > > not NULL it will not do anything, i.e., it WILL only be called when > > draining.
Since the getDrainCount() function was previously called outside the if-statement (drainCount == 0) in testDrainComplete(), if there are still outstanding requests from the child ports, the drainEvent will not be set to NULL, which means getDrainCount() can be called on further ruby_hit_callbacks. This was the crux of the issue with this code. The new Queued*Ports take care of their own processing of drain events, so it shouldn't be the responsibility of the RubyPort to check them on each ruby_hit_callback. The RubyPort only needs to check if it is done with its requests. - Joel ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/1386/#review3373 ----------------------------------------------------------- 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
