Discussion:
Problem with caches in the 9084 changeset
(too old to reply)
Nathanaël Prémillieu
2012-07-01 17:47:13 UTC
Permalink
Hi,

I have a problem that has appeared with the changeset 9084:ace8383f2b7e.
gem5.fast segfaults and with gem5.debug, an assert statement breaks.
I have tested with the 9083 version and I haven't the problem.

Here is the call stack:

gem5.debug: build/ARM/mem/cache/tags/cacheset.cc:84: void
CacheSet::moveToTail(CacheBlk*): Assertion `i >= 0' failed.

Program received signal SIGABRT, Aborted.
0x00007ffff64be445 in __GI_raise (sig=<optimized out>) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
64 ../nptl/sysdeps/unix/sysv/linux/raise.c: Aucun fichier ou dossier de
ce type.
(gdb) bt
#0 0x00007ffff64be445 in __GI_raise (sig=<optimized out>) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1 0x00007ffff64c1bab in __GI_abort () at abort.c:91
#2 0x00007ffff64b710e in __assert_fail_base (fmt=<optimized out>,
assertion=0x1e35177 "i >= 0", file=0x1e35148
"build/ARM/mem/cache/tags/cacheset.cc", line=<optimized out>,
function=<optimized out>) at assert.c:94
#3 0x00007ffff64b71b2 in __GI___assert_fail (assertion=0x1e35177 "i >=
0", file=0x1e35148 "build/ARM/mem/cache/tags/cacheset.cc", line=84,
function=0x1e351c0 "void CacheSet::moveToTail(CacheBlk*)") at assert.c:103
#4 0x0000000001660d03 in CacheSet::moveToTail (this=0x3ffb4f0,
blk=0x39bbcd0) at build/ARM/mem/cache/tags/cacheset.cc:84
#5 0x0000000001660886 in LRU::invalidateBlk (this=0x28835b0,
blk=0x39bbcd0) at build/ARM/mem/cache/tags/lru.cc:219
#6 0x0000000001643a66 in Cache<LRU>::handleResponse (this=0x4022000,
pkt=0x820f7e0) at build/ARM/mem/cache/cache_impl.hh:998
#7 0x0000000001648183 in Cache<LRU>::MemSidePort::recvTimingResp
(this=0x28834e0, pkt=0x820f7e0) at build/ARM/mem/cache/cache_impl.hh:1651
#8 0x00000000014abd33 in SlavePort::sendTimingResp (this=0x3f36280,
pkt=0x820f7e0) at build/ARM/mem/port.cc:205
#9 0x00000000014913fc in CoherentBus::recvTimingResp (this=0x3a9e400,
pkt=0x820f7e0, master_port_id=0) at build/ARM/mem/coherent_bus.cc:208
#10 0x0000000001494d4a in
CoherentBus::CoherentBusMasterPort::recvTimingResp (this=0x3f36300,
pkt=0x820f7e0) at build/ARM/mem/coherent_bus.hh:171
#11 0x00000000014abd33 in SlavePort::sendTimingResp (this=0x390dc60,
pkt=0x820f7e0) at build/ARM/mem/port.cc:205
#12 0x00000000014acc6f in SlavePacketQueue::sendTiming (this=0x390dc98,
pkt=0x820f7e0, send_as_snoop=false) at build/ARM/mem/packet_queue.cc:235
#13 0x00000000014ac8ee in PacketQueue::trySendTiming (this=0x390dc98) at
build/ARM/mem/packet_queue.cc:147
#14 0x00000000014aca6e in PacketQueue::sendDeferredPacket
(this=0x390dc98) at build/ARM/mem/packet_queue.cc:183
#15 0x00000000014acada in PacketQueue::processSendEvent (this=0x390dc98)
at build/ARM/mem/packet_queue.cc:196
#16 0x00000000014ada66 in EventWrapper<PacketQueue,
&PacketQueue::processSendEvent>::process (this=0x390dcb8) at
build/ARM/sim/eventq.hh:591
#17 0x00000000017eb54c in EventQueue::serviceOne (this=0x27488f0) at
build/ARM/sim/eventq.cc:204
#18 0x000000000182c2bc in simulate (num_cycles=9223372036854775807) at
build/ARM/sim/simulate.cc:73
#19 0x00000000014233d9 in _wrap_simulate__SWIG_0 (args=0x3812250) at
build/ARM/python/swig/event_wrap.cc:4743
#20 0x0000000001423577 in _wrap_simulate (self=0x0, args=0x3812250) at
build/ARM/python/swig/event_wrap.cc:4792
#21 0x00007ffff77513b8 in PyEval_EvalFrameEx () from
/usr/lib/libpython2.7.so.1.0
#22 0x00007ffff771c605 in PyEval_EvalCodeEx () from
/usr/lib/libpython2.7.so.1.0
#23 0x00007ffff77518c0 in PyEval_EvalFrameEx () from
/usr/lib/libpython2.7.so.1.0
#24 0x00007ffff77525eb in PyEval_EvalFrameEx () from
/usr/lib/libpython2.7.so.1.0
#25 0x00007ffff771c605 in PyEval_EvalCodeEx () from
/usr/lib/libpython2.7.so.1.0
#26 0x00007ffff771c932 in PyEval_EvalCode () from
/usr/lib/libpython2.7.so.1.0
#27 0x00007ffff77515ff in PyEval_EvalFrameEx () from
/usr/lib/libpython2.7.so.1.0
#28 0x00007ffff771c605 in PyEval_EvalCodeEx () from
/usr/lib/libpython2.7.so.1.0
#29 0x00007ffff77518c0 in PyEval_EvalFrameEx () from
/usr/lib/libpython2.7.so.1.0
#30 0x00007ffff771c605 in PyEval_EvalCodeEx () from
/usr/lib/libpython2.7.so.1.0
#31 0x00007ffff771c932 in PyEval_EvalCode () from
/usr/lib/libpython2.7.so.1.0
#32 0x00007ffff771c9cc in PyRun_StringFlags () from
/usr/lib/libpython2.7.so.1.0
#33 0x00000000017f3ab2 in m5Main (argc=21, argv=0x7fffffffded8) at
build/ARM/sim/init.cc:256
#34 0x000000000040ad5b in main (argc=21, argv=0x7fffffffded8) at
build/ARM/sim/main.cc:57
Ali Saidi
2012-07-02 02:36:47 UTC
Permalink
Hi Nathanaël,

How have you configured your cache?

Thanks,
Ali
Post by Nathanaël Prémillieu
Hi,
I have a problem that has appeared with the changeset 9084:ace8383f2b7e.
gem5.fast segfaults and with gem5.debug, an assert statement breaks.
I have tested with the 9083 version and I haven't the problem.
gem5.debug: build/ARM/mem/cache/tags/cacheset.cc:84: void CacheSet::moveToTail(CacheBlk*): Assertion `i >= 0' failed.
Program received signal SIGABRT, Aborted.
0x00007ffff64be445 in __GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
64 ../nptl/sysdeps/unix/sysv/linux/raise.c: Aucun fichier ou dossier de ce type.
(gdb) bt
#0 0x00007ffff64be445 in __GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1 0x00007ffff64c1bab in __GI_abort () at abort.c:91
#2 0x00007ffff64b710e in __assert_fail_base (fmt=<optimized out>, assertion=0x1e35177 "i >= 0", file=0x1e35148 "build/ARM/mem/cache/tags/cacheset.cc", line=<optimized out>, function=<optimized out>) at assert.c:94
#3 0x00007ffff64b71b2 in __GI___assert_fail (assertion=0x1e35177 "i >= 0", file=0x1e35148 "build/ARM/mem/cache/tags/cacheset.cc", line=84, function=0x1e351c0 "void CacheSet::moveToTail(CacheBlk*)") at assert.c:103
#4 0x0000000001660d03 in CacheSet::moveToTail (this=0x3ffb4f0, blk=0x39bbcd0) at build/ARM/mem/cache/tags/cacheset.cc:84
#5 0x0000000001660886 in LRU::invalidateBlk (this=0x28835b0, blk=0x39bbcd0) at build/ARM/mem/cache/tags/lru.cc:219
#6 0x0000000001643a66 in Cache<LRU>::handleResponse (this=0x4022000, pkt=0x820f7e0) at build/ARM/mem/cache/cache_impl.hh:998
#7 0x0000000001648183 in Cache<LRU>::MemSidePort::recvTimingResp (this=0x28834e0, pkt=0x820f7e0) at build/ARM/mem/cache/cache_impl.hh:1651
#8 0x00000000014abd33 in SlavePort::sendTimingResp (this=0x3f36280, pkt=0x820f7e0) at build/ARM/mem/port.cc:205
#9 0x00000000014913fc in CoherentBus::recvTimingResp (this=0x3a9e400, pkt=0x820f7e0, master_port_id=0) at build/ARM/mem/coherent_bus.cc:208
#10 0x0000000001494d4a in CoherentBus::CoherentBusMasterPort::recvTimingResp (this=0x3f36300, pkt=0x820f7e0) at build/ARM/mem/coherent_bus.hh:171
#11 0x00000000014abd33 in SlavePort::sendTimingResp (this=0x390dc60, pkt=0x820f7e0) at build/ARM/mem/port.cc:205
#12 0x00000000014acc6f in SlavePacketQueue::sendTiming (this=0x390dc98, pkt=0x820f7e0, send_as_snoop=false) at build/ARM/mem/packet_queue.cc:235
#13 0x00000000014ac8ee in PacketQueue::trySendTiming (this=0x390dc98) at build/ARM/mem/packet_queue.cc:147
#14 0x00000000014aca6e in PacketQueue::sendDeferredPacket (this=0x390dc98) at build/ARM/mem/packet_queue.cc:183
#15 0x00000000014acada in PacketQueue::processSendEvent (this=0x390dc98) at build/ARM/mem/packet_queue.cc:196
#16 0x00000000014ada66 in EventWrapper<PacketQueue, &PacketQueue::processSendEvent>::process (this=0x390dcb8) at build/ARM/sim/eventq.hh:591
#17 0x00000000017eb54c in EventQueue::serviceOne (this=0x27488f0) at build/ARM/sim/eventq.cc:204
#18 0x000000000182c2bc in simulate (num_cycles=9223372036854775807) at build/ARM/sim/simulate.cc:73
#19 0x00000000014233d9 in _wrap_simulate__SWIG_0 (args=0x3812250) at build/ARM/python/swig/event_wrap.cc:4743
#20 0x0000000001423577 in _wrap_simulate (self=0x0, args=0x3812250) at build/ARM/python/swig/event_wrap.cc:4792
#21 0x00007ffff77513b8 in PyEval_EvalFrameEx () from /usr/lib/libpython2.7.so.1.0
#22 0x00007ffff771c605 in PyEval_EvalCodeEx () from /usr/lib/libpython2.7.so.1.0
#23 0x00007ffff77518c0 in PyEval_EvalFrameEx () from /usr/lib/libpython2.7.so.1.0
#24 0x00007ffff77525eb in PyEval_EvalFrameEx () from /usr/lib/libpython2.7.so.1.0
#25 0x00007ffff771c605 in PyEval_EvalCodeEx () from /usr/lib/libpython2.7.so.1.0
#26 0x00007ffff771c932 in PyEval_EvalCode () from /usr/lib/libpython2.7.so.1.0
#27 0x00007ffff77515ff in PyEval_EvalFrameEx () from /usr/lib/libpython2.7.so.1.0
#28 0x00007ffff771c605 in PyEval_EvalCodeEx () from /usr/lib/libpython2.7.so.1.0
#29 0x00007ffff77518c0 in PyEval_EvalFrameEx () from /usr/lib/libpython2.7.so.1.0
#30 0x00007ffff771c605 in PyEval_EvalCodeEx () from /usr/lib/libpython2.7.so.1.0
#31 0x00007ffff771c932 in PyEval_EvalCode () from /usr/lib/libpython2.7.so.1.0
#32 0x00007ffff771c9cc in PyRun_StringFlags () from /usr/lib/libpython2.7.so.1.0
#33 0x00000000017f3ab2 in m5Main (argc=21, argv=0x7fffffffded8) at build/ARM/sim/init.cc:256
#34 0x000000000040ad5b in main (argc=21, argv=0x7fffffffded8) at build/ARM/sim/main.cc:57
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Nathanaël Prémillieu
2012-07-02 09:17:12 UTC
Permalink
Hi,

It's the default configuration (--caches --l2cache) with the
arm_detailed cpu model.

Nathanaël
Post by Ali Saidi
Hi Nathanaël,
How have you configured your cache?
Thanks,
Ali
Post by Nathanaël Prémillieu
Hi,
I have a problem that has appeared with the changeset 9084:ace8383f2b7e.
gem5.fast segfaults and with gem5.debug, an assert statement breaks.
I have tested with the 9083 version and I haven't the problem.
gem5.debug: build/ARM/mem/cache/tags/cacheset.cc:84: void CacheSet::moveToTail(CacheBlk*): Assertion `i >= 0' failed.
Program received signal SIGABRT, Aborted.
0x00007ffff64be445 in __GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
64 ../nptl/sysdeps/unix/sysv/linux/raise.c: Aucun fichier ou dossier de ce type.
(gdb) bt
#0 0x00007ffff64be445 in __GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1 0x00007ffff64c1bab in __GI_abort () at abort.c:91
#2 0x00007ffff64b710e in __assert_fail_base (fmt=<optimized out>, assertion=0x1e35177 "i >= 0", file=0x1e35148 "build/ARM/mem/cache/tags/cacheset.cc", line=<optimized out>, function=<optimized out>) at assert.c:94
#3 0x00007ffff64b71b2 in __GI___assert_fail (assertion=0x1e35177 "i >= 0", file=0x1e35148 "build/ARM/mem/cache/tags/cacheset.cc", line=84, function=0x1e351c0 "void CacheSet::moveToTail(CacheBlk*)") at assert.c:103
#4 0x0000000001660d03 in CacheSet::moveToTail (this=0x3ffb4f0, blk=0x39bbcd0) at build/ARM/mem/cache/tags/cacheset.cc:84
#5 0x0000000001660886 in LRU::invalidateBlk (this=0x28835b0, blk=0x39bbcd0) at build/ARM/mem/cache/tags/lru.cc:219
#6 0x0000000001643a66 in Cache<LRU>::handleResponse (this=0x4022000, pkt=0x820f7e0) at build/ARM/mem/cache/cache_impl.hh:998
#7 0x0000000001648183 in Cache<LRU>::MemSidePort::recvTimingResp (this=0x28834e0, pkt=0x820f7e0) at build/ARM/mem/cache/cache_impl.hh:1651
#8 0x00000000014abd33 in SlavePort::sendTimingResp (this=0x3f36280, pkt=0x820f7e0) at build/ARM/mem/port.cc:205
#9 0x00000000014913fc in CoherentBus::recvTimingResp (this=0x3a9e400, pkt=0x820f7e0, master_port_id=0) at build/ARM/mem/coherent_bus.cc:208
#10 0x0000000001494d4a in CoherentBus::CoherentBusMasterPort::recvTimingResp (this=0x3f36300, pkt=0x820f7e0) at build/ARM/mem/coherent_bus.hh:171
#11 0x00000000014abd33 in SlavePort::sendTimingResp (this=0x390dc60, pkt=0x820f7e0) at build/ARM/mem/port.cc:205
#12 0x00000000014acc6f in SlavePacketQueue::sendTiming (this=0x390dc98, pkt=0x820f7e0, send_as_snoop=false) at build/ARM/mem/packet_queue.cc:235
#13 0x00000000014ac8ee in PacketQueue::trySendTiming (this=0x390dc98) at build/ARM/mem/packet_queue.cc:147
#14 0x00000000014aca6e in PacketQueue::sendDeferredPacket (this=0x390dc98) at build/ARM/mem/packet_queue.cc:183
#15 0x00000000014acada in PacketQueue::processSendEvent (this=0x390dc98) at build/ARM/mem/packet_queue.cc:196
#16 0x00000000014ada66 in EventWrapper<PacketQueue, &PacketQueue::processSendEvent>::process (this=0x390dcb8) at build/ARM/sim/eventq.hh:591
#17 0x00000000017eb54c in EventQueue::serviceOne (this=0x27488f0) at build/ARM/sim/eventq.cc:204
#18 0x000000000182c2bc in simulate (num_cycles=9223372036854775807) at build/ARM/sim/simulate.cc:73
#19 0x00000000014233d9 in _wrap_simulate__SWIG_0 (args=0x3812250) at build/ARM/python/swig/event_wrap.cc:4743
#20 0x0000000001423577 in _wrap_simulate (self=0x0, args=0x3812250) at build/ARM/python/swig/event_wrap.cc:4792
#21 0x00007ffff77513b8 in PyEval_EvalFrameEx () from /usr/lib/libpython2.7.so.1.0
#22 0x00007ffff771c605 in PyEval_EvalCodeEx () from /usr/lib/libpython2.7.so.1.0
#23 0x00007ffff77518c0 in PyEval_EvalFrameEx () from /usr/lib/libpython2.7.so.1.0
#24 0x00007ffff77525eb in PyEval_EvalFrameEx () from /usr/lib/libpython2.7.so.1.0
#25 0x00007ffff771c605 in PyEval_EvalCodeEx () from /usr/lib/libpython2.7.so.1.0
#26 0x00007ffff771c932 in PyEval_EvalCode () from /usr/lib/libpython2.7.so.1.0
#27 0x00007ffff77515ff in PyEval_EvalFrameEx () from /usr/lib/libpython2.7.so.1.0
#28 0x00007ffff771c605 in PyEval_EvalCodeEx () from /usr/lib/libpython2.7.so.1.0
#29 0x00007ffff77518c0 in PyEval_EvalFrameEx () from /usr/lib/libpython2.7.so.1.0
#30 0x00007ffff771c605 in PyEval_EvalCodeEx () from /usr/lib/libpython2.7.so.1.0
#31 0x00007ffff771c932 in PyEval_EvalCode () from /usr/lib/libpython2.7.so.1.0
#32 0x00007ffff771c9cc in PyRun_StringFlags () from /usr/lib/libpython2.7.so.1.0
#33 0x00000000017f3ab2 in m5Main (argc=21, argv=0x7fffffffded8) at build/ARM/sim/init.cc:256
#34 0x000000000040ad5b in main (argc=21, argv=0x7fffffffded8) at build/ARM/sim/main.cc:57
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Ali Saidi
2012-07-02 18:08:35 UTC
Permalink
I still haven't seen in happen. How long does it take for it to
occur? Can you make it happen during boot?

Thanks,

Ali

On
Post by Nathanaël Prémillieu
Hi,
It's the
default configuration (--caches --l2cache) with the
Post by Nathanaël Prémillieu
arm_detailed cpu
model.
Post by Nathanaël Prémillieu
Nathanaël
Nathanaël Prémillieu
2012-07-03 12:03:54 UTC
Permalink
I am using SE mode. And this problem does not happen for all my
simulations. I have only five runs that have the problem. I also use
more memory than the default (2048MB instead of 512MB).
If you want, I can upload somewhere one of my checkpoint that have the
problem.
From what I have seen (looking at the call stack), it seems that the
invalidateBlk function is called in the case where the current blk is
the 'tempBlock'. I don't understand the whole code of the cache and
memory system, but it seems that this block is not really a block of the
cache. So trying to put it at the tail of some queue is maybe not possible.

Nathanaël
I still haven't seen in happen. How long does it take for it to occur?
Can you make it happen during boot?
Thanks,
Ali
Post by Nathanaël Prémillieu
Hi,
It's the default configuration (--caches --l2cache) with the
arm_detailed cpu model.
Nathanaël
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Lena Olson
2012-07-03 18:25:23 UTC
Permalink
Hi Nathanaël,

Oops, I didn't notice that case. If you change the moveToTail to be
within the if blk->isValid() block above it, does that fix the problem
for you?

Lena
I am using SE mode. And this problem does not happen for all my simulations.
I have only five runs that have the problem. I also use more memory than the
default (2048MB instead of 512MB).
If you want, I can upload somewhere one of my checkpoint that have the
problem.
From what I have seen (looking at the call stack), it seems that the
invalidateBlk function is called in the case where the current blk is the
'tempBlock'. I don't understand the whole code of the cache and memory
system, but it seems that this block is not really a block of the cache. So
trying to put it at the tail of some queue is maybe not possible.
Nathanaël
I still haven't seen in happen. How long does it take for it to occur?
Can you make it happen during boot?
Thanks,
Ali
Post by Nathanaël Prémillieu
Hi,
It's the default configuration (--caches --l2cache) with the
arm_detailed cpu model.
Nathanaël
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Nathanaël Prémillieu
2012-07-04 13:10:59 UTC
Permalink
Hi,

Thanks, it seems to work. I will do more tests just to be sure.

Nathanaël
Post by Ali Saidi
Hi Nathanaël,
Oops, I didn't notice that case. If you change the moveToTail to be
within the if blk->isValid() block above it, does that fix the problem
for you?
Lena
I am using SE mode. And this problem does not happen for all my simulations.
I have only five runs that have the problem. I also use more memory than the
default (2048MB instead of 512MB).
If you want, I can upload somewhere one of my checkpoint that have the
problem.
From what I have seen (looking at the call stack), it seems that the
invalidateBlk function is called in the case where the current blk is the
'tempBlock'. I don't understand the whole code of the cache and memory
system, but it seems that this block is not really a block of the cache. So
trying to put it at the tail of some queue is maybe not possible.
Nathanaël
I still haven't seen in happen. How long does it take for it to occur?
Can you make it happen during boot?
Thanks,
Ali
Post by Nathanaël Prémillieu
Hi,
It's the default configuration (--caches --l2cache) with the
arm_detailed cpu model.
Nathanaël
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Loading...