Hi Lena,
Thanks for the response. I talked with Nilay about this issue. Yes, it's
the problem of physical address range. His suggestion is to add 1GB
extra memory in the Ruby part when simulating more than 3GB memory and
it works.
Thanks,
Zhenman
On 1/6/2015 10:51 AM, Lena Olson wrote:
Hi Zhenman,
I recently ran into this and I saw several previous messages on the
list about it without replies, so I figured I'd post a workaround (I'm
not sure of the best way to do a real fix).
Someone more knowledgeable might correct me, but I believe the issue
is that because of the memory gap on x86, the valid physical addresses
are between 0-3GB and 4GB-5GB when you request 4GB. Unfortunately,
DirectoryMemory doesn't know about address ranges, so it contains
entries only for addresses between 0-4GB. When you access an address
> 4GB, it triggers the assert since it falls outside the map.
The easy workaround is just to edit the constructor of the
DirectoryMemory and add the extra GB to m_size_bytes -- there's some
wasted space, but I think correctness should be okay. I suppose the
real solution is probably to make DirectoryMemory aware of address
ranges and allow it to translate the addresses internally, but I'm not
sure.
Hope this helps someone.
Lena
2014-12-15 23:09 GMT-06:00 Zhenman Fang via gem5-users
<[email protected] <mailto:[email protected]>>:
Dear all,
I tried to run X86 with 4GB memory and ruby and encountered a
problem when restoring from the checkpoint. It's OK to do
checkpoint (no ruby) though.
The problem is: it had a virtual address "0x13f635080" which could
not be translated into the physical address correctly. Actually it
translated into the same physical address as "0x13f635080". Then
an assertion will fail later when it tries to find the
corresponding cache tag. The assertion happened at
"build/X86/mem/ruby/structures/DirectoryMemory.cc:121:
AbstractEntry* DirectoryMemory::lookup(PhysAddress): Assertion
`idx < m_num_entries' failed".
Anyone can help? Thanks a lot.
The changeset for gem5-dev is 10560:dd04eb06ad42.
The command line I use: ./build/X86/gem5.opt
--debug-flags=RubyCache configs/example/fs.py
--restore-with-cpu=timing -n 1 --mem-size=4GB --ruby
--garnet=fixed --topology=Mesh --checkpoint-dir=ckpt-1core -r 1
Detailed trace as below:
warn: Physical memory size specified is 4GB which is greater than
3GB. Twice the number of memory controllers would be created.
Global frequency set at 1000000000000 ticks per second
warn: DRAM device capacity (8192 Mbytes) does not match the
address range assigned (4096 Mbytes)
warn: DRAM device capacity (8192 Mbytes) does not match the
address range assigned (1024 Mbytes)
info: kernel located at:
/space/scratch/zhenman/parade/binaries/x86_64-vmlinux-2.6.22.9.smp
Listening for com_1 connection on port 3458
0: rtc: Real-time clock set to Sun Jan 1 00:00:00 2012
0: system.remote_gdb.listener: listening for remote gdb #0 on port
7002
warn: Reading current count from inactive timer.
**** REAL SIMULATION ****
info: Entering event queue @ 5234045298000. Starting simulation...
5234045300000: system.ruby.l1_cntrl0.L1Dcache: No tag match for
address: [0x13f635080, line 0x13f635080]
5234045300000: system.ruby.l1_cntrl0.L1Icache: No tag match for
address: [0x13f635080, line 0x13f635080]
5234045300000: system.ruby.l1_cntrl0.L1Icache: address:
[0x13f635080, line 0x13f635080]
5234045300000: system.ruby.l1_cntrl0.L1Icache: Allocate clearing
lock for addr: [0x13f635080, line 0x13f635080]
5234045300000: system.ruby.l1_cntrl0.L1Dcache: No tag match for
address: [0x13f635080, line 0x13f635080]
5234045305000: system.ruby.l2_cntrl0.L2cache: No tag match for
address: [0x13f635080, line 0x13f635080]
5234045305000: system.ruby.l2_cntrl0.L2cache: address:
[0x13f635080, line 0x13f635080]
5234045305000: system.ruby.l2_cntrl0.L2cache: Allocate clearing
lock for addr: [0x13f635080, line 0x13f635080]
5234045310000: system.ruby.dir_cntrl0.directory: Looking up
address: [0x13f635080, line 0x13f635080]
gem5.opt: build/X86/mem/ruby/structures/DirectoryMemory.cc:121:
AbstractEntry* DirectoryMemory::lookup(PhysAddress): Assertion
`idx < m_num_entries' failed.
Program received signal SIGABRT, Aborted.
0x000000371c832635 in raise () from /lib64/libc.so.6
Missing separate debuginfos, use: debuginfo-install
glibc-2.12-1.132.el6_5.4.x86_64
gperftools-libs-2.0-11.el6.3.x86_64 keyutils-libs-1.4-4.el6.x86_64
krb5-libs-1.10.3-15.el6_5.1.x86_64
libcom_err-1.41.12-18.el6_5.1.x86_64
libselinux-2.0.94-5.3.el6_4.1.x86_64 libunwind-1.1-2.el6.x86_64
openssl-1.0.1e-16.el6_5.15.x86_64 python-libs-2.6.6-52.el6.x86_64
zlib-1.2.3-29.el6.x86_64
(gdb) bt
#0 0x000000371c832635 in raise () from /lib64/libc.so.6
#1 0x000000371c833e15 in abort () from /lib64/libc.so.6
#2 0x000000371c82b75e in __assert_fail_base () from /lib64/libc.so.6
#3 0x000000371c82b820 in __assert_fail () from /lib64/libc.so.6
#4 0x00000000005ef76b in DirectoryMemory::lookup(Address) () at
build/X86/mem/ruby/structures/DirectoryMemory.cc:121
#5 0x000000000055efe5 in
Directory_Controller::getDirectoryEntry(Address const&) () at
build/X86/mem/protocol/Directory_Controller.cc:670
#6 0x000000000055f0a3 in
Directory_Controller::getState(Directory_TBE*, Address const&) ()
at build/X86/mem/protocol/Directory_Controller.cc:687
#7 0x0000000000564dab in
Directory_Controller::doTransition(Directory_Event,
Directory_TBE*, Address) () at
build/X86/mem/protocol/Directory_Transitions.cc:27
#8 0x0000000000567b1a in Directory_Controller::wakeup() () at
build/X86/mem/protocol/Directory_Wakeup.cc:54
#9 0x000000000080adb1 in EventQueue::serviceOne() () at
build/X86/sim/eventq.cc:228
#10 0x0000000000827980 in doSimLoop(EventQueue*) () at
build/X86/sim/simulate.cc:195
#11 0x0000000000827f94 in simulate(unsigned long) () at
build/X86/sim/simulate.cc:127
#12 0x000000000044366c in _wrap_simulate () at
build/X86/python/swig/event_wrap.cc:5499
#13 0x000000371f8d55c6 in PyEval_EvalFrameEx () from
/usr/lib64/libpython2.6.so.1.0
#14 0x000000371f8d7657 in PyEval_EvalCodeEx () from
/usr/lib64/libpython2.6.so.1.0
#15 0x000000371f8d5aa4 in PyEval_EvalFrameEx () from
/usr/lib64/libpython2.6.so.1.0
#16 0x000000371f8d6b8f in PyEval_EvalFrameEx () from
/usr/lib64/libpython2.6.so.1.0
#17 0x000000371f8d6b8f in PyEval_EvalFrameEx () from
/usr/lib64/libpython2.6.so.1.0
#18 0x000000371f8d7657 in PyEval_EvalCodeEx () from
/usr/lib64/libpython2.6.so.1.0
#19 0x000000371f8d7732 in PyEval_EvalCode () from
/usr/lib64/libpython2.6.so.1.0
#20 0x000000371f8d5c92 in PyEval_EvalFrameEx () from
/usr/lib64/libpython2.6.so.1.0
#21 0x000000371f8d7657 in PyEval_EvalCodeEx () from
/usr/lib64/libpython2.6.so.1.0
#22 0x000000371f8d5aa4 in PyEval_EvalFrameEx () from
/usr/lib64/libpython2.6.so.1.0
#23 0x000000371f8d7657 in PyEval_EvalCodeEx () from
/usr/lib64/libpython2.6.so.1.0
#24 0x000000371f8d7732 in PyEval_EvalCode () from
/usr/lib64/libpython2.6.so.1.0
#25 0x000000371f8f1bac in ?? () from /usr/lib64/libpython2.6.so.1.0
#26 0x000000371f8f1dba in PyRun_StringFlags () from
/usr/lib64/libpython2.6.so.1.0
#27 0x0000000000811fef in m5Main(int, char**) () at
build/X86/sim/init.cc:221
#28 0x000000000041a4b3 in main () at build/X86/sim/main.cc:58
Thanks,
Zhenman Fang
Postdoc, CS, UCLA
_______________________________________________
gem5-users mailing list
[email protected] <mailto:[email protected]>
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
