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]> : > 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] > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
