> 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?
>
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?
- 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
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
