> 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.
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?
- Cagdas
-----------------------------------------------------------
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
