Hi, Matthias. Things seem to have moved on quite a bit in the mutex behaviour
of simulate.cc. The SystemC interworking replaces the simulation loop and
hasn't kept up.
I think I've recreated your problem and I believe it's related to event queue
swapping using ScopedMigration. I believe the problem is that that class
unlocks and then locks mutexes on two event queues which, in this case, are the
same queue. Unfortunately, the SystemC event loop didn't lock the mutex in the
first place and so after destruction of the ScopedMigration, the mutex is left
locked rather than unlocked.
I believe that inserting:
std::lock_guard<EventQueue> lock(*eventq);
Near the start of Module::serviceAsyncEvent in util/systemc/sc_module.cc fixes
the problem (Well, it helped for me). This is lock_guard matches a similar one
used in doSimLoop():
// Take the event queue lock in case any of the service
// routines want to schedule new events.
std::lock_guard<EventQueue> lock(*eventq);
This is a bit of a 'voodoo' fix and there will no doubt be other things that
need to be worried about.
Hope that helps.
- Andrew
-----Original Message-----
From: gem5-dev [mailto:[email protected]] On Behalf Of Matthias Jung
Sent: 14 July 2015 12:58
To: [email protected]
Subject: [gem5-dev] Deadlock in SystemC Simulation
Hi,
the SystemC based simulation is locked when an input event on the terminal
happens. It is easy to reproduce:
build the gem5 SystemC version as described in utils/systemc. Then, run this in
utils/systemc to generate the gem5 config:
../../build/ARM/gem5.opt ../../configs/example/fs.py \
--cpu-type=timing \
--num-cpu=1 \
--mem-type=SimpleMemory \
--mem-size=512MB \
--mem-channels=1 \
--caches --l2cache \
--machine-type=VExpress_EMM \
--dtb-filename=vexpress.aarch32.ll_20131205.0-gem5.1cpu.dtb \
--kernel=vmlinux.aarch32.ll_20131205.0-gem5
then execute the systemc version of gem5 with the generated config.ini:
gdb gem5.debug.sc
run m5out/config.ini
then I connect the terminal and put in some input and press enter —> locked
forever.
gdb output:
#0 0x00007ffff5284264 in __lll_lock_wait () from /lib64/libpthread.so.0
#1 0x00007ffff527f508 in _L_lock_854 () from /lib64/libpthread.so.0
#2 0x00007ffff527f3d7 in pthread_mutex_lock () from /lib64/libpthread.so.0
#3 0x00007ffff6be0ab5 in gthread_mutex_lock (mutex=0x700128) at
/opt/gcc-4.8.2/include/c++/4.8.2/x86_64-unknown-linux-gnu/bits/gthr-default.h:748
#4 lock (this=0x700128) at /opt/gcc-4.8.2/include/c++/4.8.2/mutex:134
#5 lock (this=0x7000d0) at build/ARM/sim/eventq.hh:645
#6 lock_guard (__m=..., this=<synthetic pointer>) at
/opt/gcc-4.8.2/include/c++/4.8.2/mutex:414
#7 EventQueue::serviceOne (this=0x7000d0) at build/ARM/sim/eventq.cc:206
#8 0x0000000000413886 in Gem5SystemC::Module::eventLoop (this=0x7fffffffd250)
at ../systemc/sc_module.cc:236
#9 0x00007ffff6081529 in sc_core::sc_simcontext::crunch(bool) () from
/opt/systemc/lib-linux64/libsystemc-2.3.0.so
#10 0x00007ffff607e582 in sc_core::sc_simcontext::simulate(sc_core::sc_time
const&) () from /opt/systemc/lib-linux64/libsystemc-2.3.0.so
#11 0x00007ffff607f1a9 in sc_core::sc_start(sc_core::sc_time const&,
sc_core::sc_starvation_policy) () from
/opt/systemc/lib-linux64/libsystemc-2.3.0.so
#12 0x00007ffff607f2dc in sc_core::sc_start() () from
/opt/systemc/lib-linux64/libsystemc-2.3.0.so
#13 0x000000000040b89d in sc_main (argc=4, argv=0x68b710) at main.cc:320
#14 0x00007ffff606e8fb in sc_elab_and_sim () from
/opt/systemc/lib-linux64/libsystemc-2.3.0.so
#15 0x00007ffff54b1d5d in __libc_start_main () from /lib64/libc.so.6
#16 0x000000000040a369 in _start ()
there is an issue deeply in gem5 and I have no idea what is happening. Maybe an
expert gem5 developer will solve this, easily.
thx for your help
matthias
—
Dipl.-Ing. Matthias Jung
Member
Advanced Silicon Technologies & Design Methodologies
University of Kaiserslautern
Microelectronic Systems Design Research Group Erwin-Schrödinger-Straße 12/228
67663 Kaiserslautern, Germany
Phone: +49 631 205 3579
Fax: +49 631 205 4437
[email protected]
http://ems.eit.uni-kl.de
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
-- IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient,
please notify the sender immediately and do not disclose the contents to any
other person, use it for any purpose, or store or copy the information in any
medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered
in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2548782
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
