[m5-users] no contention bus in detailed simulation
Hi,
I recently pulled down the current m5-stable repository to do some
testing, and I patched it with my changes from our group's older repository
(versions below). When I try to run some of our tests, I get a segmentation
fault. I have traced it back to our modification the the bus in
./src/mem/bus.cc. We had modified calcPacketTiming so that we could simulate
a zero-latency/no-contention bus in detailed simulation (recvTiming). I am
not sure where to start debugging this problem. I have attached the gdb
output.
Is there, perhaps, a better way to simulate a bus with no contention in
detailed simulation?
Thanks,
Joel
Revisions:
Old: changeset: 5589:733318abb7b1
Current: changeset: 6283:94c016415053
--
Joel Hestness
PhD Student, Computer Architecture
Dept. of Computer Science, University of Texas - Austin
http://www.cs.utexas.edu/~hestness
gdb --args ./build/ALPHA_FS/m5.debug --trace-flags=Bus
--trace-start=182876000 --trace-file=tracelog.txt ./configs/example/fs.py
--script=../m5-parsec/bash-m5/test.rcS --detailed --caches --l2cache
--fast-forward=100
j...@capillary:~/research/m5-stable$ gdb --args ./build/ALPHA_FS/m5.debug
--trace-flags=Bus --trace-start=182876000 --trace-file=tracelog.txt
./configs/example/fs.py --script=../m5-parsec/bash-m5/test.rcS --detailed
--caches --l2cache --fast-forward=1
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as i486-linux-gnu...
(gdb) run
Starting program: /home/joel/research/m5-stable/build/ALPHA_FS/m5.debug
--trace-flags=Bus --trace-start=182876000 --trace-file=tracelog.txt
./configs/example/fs.py --script=../m5-parsec/bash-m5/test.rcS --detailed
--caches --l2cache --fast-forward=1
[Thread debugging using libthread_db enabled]
[New Thread 0xb7a9d8e0 (LWP 3241)]
M5 Simulator System
Copyright (c) 2001-2008
The Regents of The University of Michigan
All Rights Reserved
M5 compiled Nov 27 2009 01:36:44
M5 revision 94c016415053+ 6283+ default tip
M5 started Nov 27 2009 01:40:21
M5 executing on capillary
command line: /home/joel/research/m5-stable/build/ALPHA_FS/m5.debug
--trace-flags=Bus --trace-start=182876000 --trace-file=tracelog.txt
./configs/example/fs.py --script=../m5-parsec/bash-m5/test.rcS --detailed
--caches --l2cache --fast-forward=1
Global frequency set at 1 ticks per second
info: kernel located at: /home/joel/research/m5-parsec/binaries/vmlinux
Listening for system connection on port 3456
0: system.remote_gdb.listener: listening for remote gdb #0 on port 7000
Switch at instruction count:1
info: Entering event queue @ 0. Starting simulation...
hack: be nice to actually delete the event here
Switched CPUS @ cycle = 1828747071000
Changing memory mode to timing
switching cpus
REAL SIMULATION
info: Entering event queue @ 1828747071000. Starting simulation...
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb7a9d8e0 (LWP 3241)]
0x080befe0 in std::listPacket*, std::allocatorPacket* ::empty (this=0x4) at
/usr/include/c++/4.3/bits/stl_list.h:759
759 { return this-_M_impl._M_node._M_next == this-_M_impl._M_node;
}
(gdb) info stack
#0 0x080befe0 in std::listPacket*, std::allocatorPacket* ::empty
(this=0x4) at /usr/include/c++/4.3/bits/stl_list.h:759
#1 0x080b8f03 in BasePrefetcher::getPacket (this=0x0) at
build/ALPHA_FS/mem/cache/prefetch/base.cc:134
#2 0x08112493 in CacheLRU::getNextMSHR (this=0x9d655a0) at
build/ALPHA_FS/mem/cache/cache_impl.hh:1307
#3 0x08112532 in CacheLRU::getTimingPacket (this=0x9d655a0) at
build/ALPHA_FS/mem/cache/cache_impl.hh:1325
#4 0x08112744 in CacheLRU::MemSidePort::sendPacket (this=0x9d93790) at
build/ALPHA_FS/mem/cache/cache_impl.hh:1518
#5 0x0811364e in CacheLRU::MemSidePort::processSendEvent (this=0x9d93790) at
build/ALPHA_FS/mem/cache/cache_impl.hh:1575
#6 0x0810a41c in EventWrapperCacheLRU::MemSidePort,
(CacheLRU::MemSidePort::processSendEvent())::process (this=0x9456df0)
at build/ALPHA_FS/sim/eventq.hh:468
#7 0x082233de in EventQueue::serviceOne (this=0x884eeb8) at
build/ALPHA_FS/sim/eventq.cc:202
#8 0x08587dcc in simulate (num_cycles=9223372036854775807) at
build/ALPHA_FS/sim/simulate.cc:73
#9 0x085fa28d in _wrap_simulate__SWIG_0 (args=0x9435acc) at
build/ALPHA_FS/python/swig/event_wrap.cc:4156
#10 0x085fa395 in _wrap_simulate (self=0x0, args=0x9435acc) at
build/ALPHA_FS/python/swig/event_wrap.cc:4206
#11 0xb7dadaed in PyCFunction_Call () from /usr/lib/libpython2.6.so.1.0
#12 0xb7d6798c in PyObject_Call () from /usr/lib/libpython2.6.so.1.0
#13 0xb7e0d0b5 in PyEval_EvalFrameEx () from /usr/lib/libpython2.6.so.1.0
#14 0xb7e11910 in
Re: [m5-users] no contention bus in detailed simulation
and the attachment... On Fri, Nov 27, 2009 at 6:31 PM, Joel Hestness hestn...@cs.utexas.eduwrote: Hi Steve, Thanks for the quick response. I tried the m5 repository and ran into the same issue. I have attached the updated src/mem/bus.cc that we had in our old source. The changes that cause the problem are in calcPacketTiming, updating tickNextIdle and the packet firstWordTime and finishTime. Thanks, Joel On Fri, Nov 27, 2009 at 4:14 PM, Steve Reinhardt ste...@gmail.com wrote: This bug may or may not be related to your changes; there were a number of prefetcher bugs that I worked through a while ago and I'm not sure if they're in m5-stable or not.. In general, m5-stable is pretty stale and we haven't been very good about pushing bug fixes there, so if you're trying to bring your code up to date it's much better to go with the main m5 repository than m5-stable. If you still have trouble at that point, let us know. Steve On Fri, Nov 27, 2009 at 12:32 PM, Joel Hestness hestn...@cs.utexas.edu wrote: Hi, I recently pulled down the current m5-stable repository to do some testing, and I patched it with my changes from our group's older repository (versions below). When I try to run some of our tests, I get a segmentation fault. I have traced it back to our modification the the bus in ./src/mem/bus.cc. We had modified calcPacketTiming so that we could simulate a zero-latency/no-contention bus in detailed simulation (recvTiming). I am not sure where to start debugging this problem. I have attached the gdb output. Is there, perhaps, a better way to simulate a bus with no contention in detailed simulation? Thanks, Joel Revisions: Old: changeset: 5589:733318abb7b1 Current: changeset: 6283:94c016415053 -- Joel Hestness PhD Student, Computer Architecture Dept. of Computer Science, University of Texas - Austin http://www.cs.utexas.edu/~hestness ___ m5-users mailing list m5-users@m5sim.org http://m5sim.org/cgi-bin/mailman/listinfo/m5-users ___ m5-users mailing list m5-users@m5sim.org http://m5sim.org/cgi-bin/mailman/listinfo/m5-users -- Joel Hestness PhD Student, Computer Architecture Dept. of Computer Science, University of Texas - Austin http://www.cs.utexas.edu/~hestness -- Joel Hestness PhD Student, Computer Architecture Dept. of Computer Science, University of Texas - Austin http://www.cs.utexas.edu/~hestness bus.cc Description: Binary data ___ m5-users mailing list m5-users@m5sim.org http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
