Hey,
first of all thanks for your kind help. I really appreciate it. Here is
the gdb backtrace:
#0 0x00007ffff638dd05 in raise (sig=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1 0x00007ffff6391ab6 in abort () at abort.c:92
#2 0x00007ffff63867c5 in __assert_fail (assertion=0xca8b1b "hash_it !=
memDepHash.end()", file=<value optimized out>, line=535, function=<value
optimized out>) at assert.c:81
#3 0x00000000006f1b1b in findInHash (this=0x1e298c0, inst=...) at
build/ALPHA_FS/cpu/o3/mem_dep_unit_impl.hh:535
#4 MemDepUnit<StoreSet, O3CPUImpl>::wakeDependents (this=0x1e298c0,
inst=...) at build/ALPHA_FS/cpu/o3/mem_dep_unit_impl.hh:435
#5 0x00000000006c9f72 in InstructionQueue<O3CPUImpl>::wakeDependents
(this=0x1e298a8, completed_inst=...) at
build/ALPHA_FS/cpu/o3/inst_queue_impl.hh:968
#6 0x000000000069ec7f in DefaultIEW<O3CPUImpl>::writebackInsts
(this=0x1e29540) at build/ALPHA_FS/cpu/o3/iew_impl.hh:1464
#7 0x00000000006aed75 in DefaultIEW<O3CPUImpl>::tick (this=0x1e29540) at
build/ALPHA_FS/cpu/o3/iew_impl.hh:1515
#8 0x000000000064425e in FullO3CPU<O3CPUImpl>::tick (this=0x1e28520) at
build/ALPHA_FS/cpu/o3/cpu.cc:549
#9 0x0000000000409b94 in EventQueue::serviceOne (this=<value optimized
out>) at build/ALPHA_FS/sim/eventq.cc:204
#10 0x00000000004561d2 in simulate (num_cycles=9223372036854775807) at
build/ALPHA_FS/sim/simulate.cc:73
#11 0x000000000089ded9 in _wrap_simulate__SWIG_0 (self=<value optimized
out>, args=<value optimized out>) at
build/ALPHA_FS/python/swig/event_wrap.cc:4534
#12 _wrap_simulate (self=<value optimized out>, args=<value optimized
out>) at build/ALPHA_FS/python/swig/event_wrap.cc:4584
#13 0x00007ffff73af0b1 in PyEval_EvalFrameEx () from
/usr/lib/libpython2.7.so.1.0
#14 0x00007ffff73b127d in PyEval_EvalCodeEx () from
/usr/lib/libpython2.7.so.1.0
#15 0x00007ffff73af28d in PyEval_EvalFrameEx () from
/usr/lib/libpython2.7.so.1.0
#16 0x00007ffff73aff8c in PyEval_EvalFrameEx () from
/usr/lib/libpython2.7.so.1.0
#17 0x00007ffff73b127d in PyEval_EvalCodeEx () from
/usr/lib/libpython2.7.so.1.0
#18 0x00007ffff73b1392 in PyEval_EvalCode () from
/usr/lib/libpython2.7.so.1.0
#19 0x00007ffff73b0228 in PyEval_EvalFrameEx () from
/usr/lib/libpython2.7.so.1.0
#20 0x00007ffff73b127d in PyEval_EvalCodeEx () from
/usr/lib/libpython2.7.so.1.0
#21 0x00007ffff73af28d in PyEval_EvalFrameEx () from
/usr/lib/libpython2.7.so.1.0
#22 0x00007ffff73b127d in PyEval_EvalCodeEx () from
/usr/lib/libpython2.7.so.1.0
#23 0x00007ffff73b1392 in PyEval_EvalCode () from
/usr/lib/libpython2.7.so.1.0
#24 0x00007ffff73d31dc in PyRun_StringFlags () from
/usr/lib/libpython2.7.so.1.0
#25 0x000000000041a35f in m5Main (argc=<value optimized out>,
argv=<value optimized out>) at build/ALPHA_FS/sim/init.cc:256
#26 0x0000000000408371 in main (argc=5, argv=0x7fffffffe168) at
build/ALPHA_FS/sim/main.cc:57
Seems like the assertion is failing. However, if you put a printf
command behind the assertion check, this is executed?!
@Steve:
I have the newest (unstable)-release, so the bug you mentioned is not
included. However I changed a few more parameters than just the cache
size such as TLB sizes, width of issue, dispatch, ... number of
execution units and clock frequency. That is why I asked, where I can
upload my config.ini so that you can test with my settings. Putting all
the stuff here would be too much, I guess.
Best wishes
Fabian
Am 18.07.2011 20:09, schrieb Nilay:
On Mon, July 18, 2011 9:55 am, Fabian Oboril wrote:
Sorry, I forgot to add that. The error occurs here (FindInHash function
in mem_dep_unit_impl.cc called from WakeDependents function in
inst_queue_impl):
946
<http://repo.gem5.org/gem5/file/9b48b795bfc5/src/cpu/o3/inst_queue_impl.hh#l946>
InstructionQueue<Impl>::wakeDependents(DynInstPtr&completed_inst)
[...]
967
<http://repo.gem5.org/gem5/file/9b48b795bfc5/src/cpu/o3/inst_queue_impl.hh#l967>
if (completed_inst->isMemRef()) {
968
<http://repo.gem5.org/gem5/file/9b48b795bfc5/src/cpu/o3/inst_queue_impl.hh#l968>
memDepUnit[completed_inst->threadNumber].wakeDependents(completed_inst);
969
<http://repo.gem5.org/gem5/file/9b48b795bfc5/src/cpu/o3/inst_queue_impl.hh#l969>
completeMemInst(completed_inst);
which calls
424
<http://repo.gem5.org/gem5/file/9b48b795bfc5/src/cpu/o3/mem_dep_unit_impl.hh#l424>
MemDepUnit<MemDepPred, Impl>::wakeDependents(DynInstPtr&inst)
[...]
431
<http://repo.gem5.org/gem5/file/9b48b795bfc5/src/cpu/o3/mem_dep_unit_impl.hh#l431>
MemDepEntryPtr inst_entry = findInHash(inst);
which calls at some point,
assert(hash_it != memDepHash.end());
which leads to the segmentation fault.
Best wishes
Fabian
Am 18.07.2011 16:32, schrieb Nilay:
On Mon, July 18, 2011 6:48 am, Fabian Oboril wrote:
Hi,
when I use the actual version (the most recent unstable from today),
exactly the same error occurs! Can I upload somewhere my configuration
files?
Best wishes
Fabian
Am 14.07.2011 16:19, schrieb Nilay:
On Thu, July 14, 2011 8:02 am, Fabian Oboril wrote:
Hi guys,
I have a problem with M5 and the FS mode with ALPHA. The version I am
using is based on a release in February which I modified for my own
purpose, so may be the problem I face is due to my additions.
However,
I
don't know this, I basically have no idea where the problem comes
from,
right now.
If I decrease the size of the L2-Cache (detailed mode with L1&
L2-Cache) from 2 MByte to 512 KByte I get an segmentation fault when
booting in FS mode. The last actions thereby are:
init started: BusyBox v1.1.0 (2007.03.04-01:07+0000) multi-call
binary
mounting filesystems...
Has anyone seen such a behavior before or has an idea what my be the
root cause for the segmentation fault? With 2 MByte L2-Cache
everything
is working fine...
I do not expect booting of the operating system can be affected by the
size of the cache. To figure out where the problem is, try booting
with
unmodified gem5 and 512kb of cache.
Use gdb and track where the segmentation fault occurs. Post the function
call stack trace, that should help in figuring out the problem.
Are you saying that the assert failed? Assertion failure is different from
a segmentation fault. Again, would it possible for you to provide a call
stack trace from gdb?
--
Nilay
_______________________________________________
gem5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
--
Karlsruhe Institute of Technology (KIT)
Chair of Dependable Nano Computing (CDNC)
Institut für Technische Informatik (ITEC)
Dipl.-Math. techn. Fabian Oboril
Research Associate
Haid-und-Neu-Str. 7
Building 07.21
76131 Karlsruhe, Germany
Phone: +49 721 608-44859
Fax: +49 721 608-43962
Email: fabian.oboril∂kit edu
Web: http://cdnc.itec.kit.edu/
KIT – University of the State of Baden-Wuerttemberg and
National Research Center of the Helmholtz Association
_______________________________________________
gem5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
