I am having a page table fault issue when running a benchmark on ARM_SE. The error message I got was:
[.] warn: mremapping to totally new vaddr 0x416ce000-0x41746000, adding 491520 warn: returning 0x416ce000 as start warn: mremapping to totally new vaddr 0x41746000-0x4193c000, adding 2056192 warn: returning 0x41746000 as start warn: Not extending stack: address 0x41421758 isn't at the end of the stack. panic: Page table fault when accessing virtual address 0x41421758 @ cycle 786760171000 [invoke:build/ARM_SE/sim/faults.cc, line 70] Memory Usage: 2197968 KBytes Program aborted at cycle 786760171000 Abort (core dumped) It seems to me that the address 0x41421758 is not in the emulated page table. However, the log shows "mremapping" adds the memory space up to 0x4193c000 already. Also, the most interesting thing is: this issue CANNOT be reproduced on another almost identical machine (I mean it can run successfully on another machine as follows): [.] warn: mremapping to totally new vaddr 0x416ce000-0x41746000, adding 491520 warn: returning 0x416ce000 as start warn: mremapping to totally new vaddr 0x41746000-0x4193c000, adding 2056192 warn: returning 0x41746000 as start warn: mremapping to totally new vaddr 0x4193c000-0x41a29000, adding 970752 warn: returning 0x4193c000 as start warn: mremapping to totally new vaddr 0x41a41000-0x41ad1000, adding 589824 warn: returning 0x41a41000 as start [.] [looks like it's going to run forever] 1. two machines (both linux 2.6 on x86-64), the failed one has larger memory size. 2. I have identical source codes on these two machines 3. I compile the source codes cleanly 4. I set the same "ulimit" 5. The only difference I can see is the compiler toolchain: one uses GCC 4.4.5/Python 2.6.7, one uses GCC4.4.6/Python 2.6.6 I would appreciate it very much if someone can give me some hints. Thank you!
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
