> On Nov. 19, 2014, 12:22 a.m., Cagdas Dirik wrote: > > Please ignore my last review. I made a mistake with my patches. > > > > In FS, X86 mode I was able to boot with python variant, checkpoint, run a > > short program. Then I was able to restore from checkpoint and run the same > > program again. And in systemc variant then I was able to restore from > > checkpoint and run the same program. > > > > The exit was not clean though. It failed with > > fatal: Missed an event at time 123366500 gem5: 5699875688000, SystemC: > > 5699875688000 @ tick 5699875688000 > > [eventLoop:sc_module.cc, line 192] > > > > But that may be due to m5_exit in the test program. > > > > Andrew Bardsley wrote: > Hmm. The problem seems to be that sometimes asynchronous events schedule > actions based on gem5 time in the asynchronous event handler. I'm adding > code to catch up time in that handler and also a bit more 'in_simulate' > checking and general event management to fix the problem. > > A patch will follow... > > Andrew Bardsley wrote: > Oh, in the meantime, can you put the line: > > getEventQueue(0)->setCurTick(systemc_time); > > Near the top of serviceAsyncEvent and see if that helps.
Unfortunately that did not resolve the issue. Debugging it a bit more, here is what I believe is going wrong: There is no sync point between gem5 curTick and sc_time_stamp(). Therefore, all events in the system are gem5 events based on curTick. Somewhere between SimControl::SimControl, SimControl::before_end_of_elaboration, and SimControl::run(), gem5 sub-system starts ticking before systemc starts SimControl::run(). And then we go into wait statement to advance systemc time, but gem5 keeps ticking. No gem5 module knows about systemc scheduler and the fact that they have to wait if we are restoring from a checkpoint. So gem5 events gets scheduled just like normal execution, and shortly after things fall apart because curTick, sc_time_stamp, checkpoint time and event times are totally out of whack. - Cagdas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2504/#review5482 ----------------------------------------------------------- On Nov. 17, 2014, 6:19 a.m., Andreas Hansson wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/2504/ > ----------------------------------------------------------- > > (Updated Nov. 17, 2014, 6:19 a.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 10555:d1e51dc6cf86 > --------------------------- > config: Fix to SystemC example's event handling > > This patch fixes checkpoint restore in the SystemC hosting example by handling > early PollEvent events correctly before any EventQueue events are posted. > > The SystemC event queue handler (SCEventQueue) reports an error if the event > loop is entered with no Events posted. It is possible for this to happen > after instantiate due to PollEvent events. This patch separates out > `external' events into a different handler in sc_module.cc to prevent the > error from occurring. > > > Diffs > ----- > > util/systemc/Makefile 1a9e235cab09 > util/systemc/main.cc 1a9e235cab09 > util/systemc/sc_module.hh 1a9e235cab09 > util/systemc/sc_module.cc 1a9e235cab09 > > Diff: http://reviews.gem5.org/r/2504/diff/ > > > Testing > ------- > > > Thanks, > > Andreas Hansson > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
