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

Reply via email to