> On Nov. 20, 2014, 8:54 p.m., Cagdas Dirik wrote: > > I am afraid you have to move config_manager->instantiate() call into > > SimControl::run() after wait. > > > > Currently it is tripping at: > > fatal condition !eventq->empty() occurred: There must be no posted events > > before SimControl::run @ tick 0 > > [run:main.cc, line 266] > > > > If add add getEventQueue(0)->dump() after config_manager->instantiate(), > > this is what I get: > > > > SimControl::SimControl(sc_core::sc_module_name name,.... > > { > > .... > > CxxConfig::statsEnable(); > > getEventQueue(0)->dump(); > > > > try { > > config_manager->instantiate(); > > } catch (CxxConfigManager::Exception &e) { > > fatal("Config problem in sim object %s: %s", e.name, e.message); > > } > > > > ==> std::cout << "Called config_manager->instantiate()." << std::endl; > > ==> getEventQueue(0)->dump(); > > } > > > > The output is: > > > > ============================================================ > > EventQueue Dump (cycle 0) > > ------------------------------------------------------------ > > <No Events> > > ============================================================ > > info: kernel located at: > > /proj/adg/REV/sim/cdirik/gem5-sims/full-system-x86/binaries/x86_64-vmlinux-2.6.26 > > Listening for com_1 connection on port 3456 > > > > Info: rtc: Real-time clock set to Sun Jan 1 00:00:00 2012 > > 0: system.remote_gdb.listener: listening for remote gdb #0 on port 7000 > > warn: Reading current count from inactive timer. > > Called config_manager->instantiate(). > > ============================================================ > > EventQueue Dump (cycle 0) > > ------------------------------------------------------------ > > Event Event_69 (RTC interrupt) > > Flags: 0x7a42 > > Scheduled for 5000000000, priority 0 > > Event Event_80 (Intel 8254 Interval timer) > > Flags: 0x7a42 > > Scheduled for 54924621360, priority 0 > > Event Event_70 (RTC clock tick) > > Flags: 0x7a42 > > Scheduled for 1000000000000, priority 0 > > ============================================================ > > fatal condition !eventq->empty() occurred: There must be no posted events > > before SimControl::run @ tick 0 > > [run:main.cc, line 266] > > Andreas Hansson wrote: > We could also decide to enforce that there are no events scheduled in the > constructor (as I believe they should rather be scheduled in startup or > init/loadState). This will require a bit of work to chase these events down > though, but it is perhaps the right answer here? > > Cagdas Dirik wrote: > Definitely. I would be stricter and enforce events to be scheduled only > after startup. Is there a reason to have any events before startup, during > init/loadState? > > > Andreas Hansson wrote: > I believe there is a convention to only schedule events in startup(), > initState() or loadState(), but I would not be surprised if that convention > is not strictly adhered to. > > Could you have a look at the two specific examples in your use-case? > > Cagdas Dirik wrote: > Yes, I will chase them down a bit and see if I can catch where we are not > following the convention. > > Cagdas Dirik wrote: > I looked into these events which get scheduled during > config_manager->instantiate() call, and I tried to move them to corresponding > startup() calls, but system hangs very early on boot sequence. > > As a summary; > src/dev/mc146818.* have RTCEvent and RTCTickEvents that get scheduled > from constructor (which violates the guidelines). It also schedules events on > unserialize() call (which is also counter to the guidelines). > Also src/dev/intel_8254_timer.* have a Counter and CounterEvent which are > written into at the very beginning (I could not pinpoint the originator), > which results in events being scheduled. Actually X86ISA::I8254 drives > intel_8254_timer, but who is driving I8254? This module also schedules events > on unserialize() call. > > I don't have the knowledge and experience to properly fix these counter > write calls and sync them up with unserialize and startup calls. > > Could someone who is experienced with these modules give me some lead > please?
I see you've already gotten to it. Well done! Out of curiosity, have you tried an ARM system (since the X86 devices are misbehaving)? - Andreas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2504/#review5510 ----------------------------------------------------------- On Nov. 20, 2014, 3:48 p.m., Andreas Hansson wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/2504/ > ----------------------------------------------------------- > > (Updated Nov. 20, 2014, 3:48 p.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 10567:5b89628d387b > --------------------------- > 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. > > This fix also improves the event handling of asynchronous events by: > > 1) Making asynchronous events 'catch up' gem5 time to SystemC > time to avoid the appearance that events have been lost > while servicing an asynchronous event that schedules an > event loop exit event > > 2) Add an in_simulate data member to Module to allow the event > loop to check whether events should be processed or deferred > until the next time Module::simulate is entered > > 3) Cancel pending events around the entry/exit of the event loop > in Module::simulate > > 4) Moving the state initialisation of the example entirely into > run to correct a problem with early events in checkpoint > restore. > > It is still possible to schedule asynchronous events (and talk PollQueue > actions) while simulate is not running. This behaviour may stil cause > some problems. > > > Diffs > ----- > > util/systemc/Makefile b61dc895269a > util/systemc/main.cc b61dc895269a > util/systemc/sc_gem5_control.cc b61dc895269a > util/systemc/sc_logger.cc b61dc895269a > util/systemc/sc_module.hh b61dc895269a > util/systemc/sc_module.cc b61dc895269a > > Diff: http://reviews.gem5.org/r/2504/diff/ > > > Testing > ------- > > > Thanks, > > Andreas Hansson > > _______________________________________________ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev