I'd like to post my progress on solving this problem.
(It's not solved yet..)
I decided to see what's really going on when running bzip2_source on both:
* Classic memory system
* Ruby memory system.
To do so, I used the following command:
./util/tracediff build/X86/gem5.opt --debug-flags=Exec,-ExecTicks
configs/example/se_phm.py '--cpu-type=timing|--ruby' --mem-size=4GB
--bench=bzip2_source
The relevant part of the resultant tracediff file (tracediff-*.out) is:
-build/X86/gem5.opt -d tracediff-11723-1 --debug-flags=Exec,-ExecTicks
configs/example/se_phm.py --cpu-type=timing --mem-size=4GB --bench=bzip2_source
2>&1 |
+build/X86/gem5.opt -d tracediff-11723-2 --debug-flags=Exec,-ExecTicks
configs/example/se_phm.py --ruby --mem-size=4GB --bench=bzip2_source 2>&1 |
... (I omitted this part.)
@@ -5826 +5826 @@
system.cpu T0 : @_dl_non_dynamic_init+610.2 : JZ_I : wrip , t1, t2 :
IntAlu :
system.cpu T0 : @_dl_non_dynamic_init+612.0 : XOR_R_R : xor edx, edx, edx
: IntAlu : D=0x0000000000000000
system.cpu T0 : @_dl_non_dynamic_init+614.0 : CMP_M_I : limm t2d,
0x6474e551 : IntAlu : D=0x000000006474e551
-system.cpu T0 : @_dl_non_dynamic_init+614.1 : CMP_M_I : ld t1d, DS:[rcx]
: MemRead : D=0x0000000000000001 A=0x400040
+system.cpu T0 : @_dl_non_dynamic_init+614.1 : CMP_M_I : ld t1d, DS:[rcx]
: MemRead : D=0x0000000000000000 A=0x400040
system.cpu T0 : @_dl_non_dynamic_init+614.2 : CMP_M_I : sub t0d, t1d, t2d
: IntAlu : D=0x0000000000000001
system.cpu T0 : @_dl_non_dynamic_init+620.0 : LEA_R_M : lea rax, DS:[rcx
+ 0x38] : IntAlu : D=0x0000000000400078
system.cpu T0 : @_dl_non_dynamic_init+624.0 : JNZ_I : rdip t1, %ctrl153,
: IntAlu : D=0x000000000042a802
@@ -5842 +5842 @@
system.cpu T0 : @_dl_non_dynamic_init+635.0 : ADD_R_I : limm t1, 0x38 :
IntAlu : D=0x0000000000000038
system.cpu T0 : @_dl_non_dynamic_init+635.1 : ADD_R_I : add rax, rax, t1
: IntAlu : D=0x0000000000000000
system.cpu T0 : @_dl_non_dynamic_init+639.0 : CMP_M_I : limm t2d,
0x6474e551 : IntAlu : D=0x000000006474e551
-system.cpu T0 : @_dl_non_dynamic_init+639.1 : CMP_M_I : ld t1d, DS:[rax +
0xffffffffffffffc8] : MemRead : D=0x0000000000000001 A=0x400078
+system.cpu T0 : @_dl_non_dynamic_init+639.1 : CMP_M_I : ld t1d, DS:[rax +
0xffffffffffffffc8] : MemRead : D=0x0000000000000000 A=0x400078
system.cpu T0 : @_dl_non_dynamic_init+639.2 : CMP_M_I : sub t0d, t1d, t2d
: IntAlu : D=0x0000000000000001
system.cpu T0 : @_dl_non_dynamic_init+646.0 : JZ_I : rdip t1, %ctrl153,
: IntAlu : D=0x000000000042a818
system.cpu T0 : @_dl_non_dynamic_init+646.1 : JZ_I : limm t2, 0x68 :
IntAlu : D=0x0000000000000068
...
There are more differences in "... (I omitted this part)" above, but I think
that they are not relevant.
(Because those differences also occur when running the simulation without Ruby,
but with different CPU models.)
As you can see in the tracediff file above, The different behavior of the two
CPU models looks like coming from the different value of 'D' in MemRead
operations (One is '0' and the other is '1').
After 2 more similar-kind of MemRead's D-differences, the difference of the two
simulations diverges.
Can this be any clue of solving this problem?
Thanks,
Hanmin
From: 박한민 [mailto:[email protected]]
Sent: Wednesday, November 20, 2013 4:06 PM
To: '[email protected]'
Subject: Error running SPEC CPU2006 in SE mode with Ruby
Hi, all!
I’m trying to run bzip2_source of SPEC CPU2006 in SE mode with Ruby enabled.
Before showing you the details of the problem, I’d like to note that without
Ruby enabled (that is, using the Classic memory system), it runs well using the
following command:
./build/X86/gem5.opt configs/example/se_phm.py --mem-size=4GB
--bench=bzip2_source
Two things to note here:
• The configuration script above (se_phm.py) is a mere copy of the
“configs/example/se.py”, except that I modified the original to apply SPEC
CPU2006 instead of SPEC CPU2000.
• “--mem-size” option is used because without it, the simulation gives “fatal:
Out of memory, please increase size of physical memory.” error.
To enable Ruby, I added “--ruby” option and used the following command to run
the simulation:
./build/X86/gem5.opt configs/example/se_phm.py --ruby --mem-size=4GB
--bench=bzip2_source
This results in “panic: Tried to read unmapped address 0x8.” error.
I first thought that this problem comes from the fact that the two simulations
use different CPU models (AtomicSimpleCPU for the Classic and TimingSimpleCPU
for Ruby).
So, I tried the Classic memory system with a TimingSimpleCPU using the
following command:
./build/X86/gem5.opt configs/example/se_phm.py --cpu-type=timing --mem-size=4GB
--bench=bzip2_source
(Note the “--cpu-type” option.)
In this case, the simulation runs well without any error.
I am stuck with not being able to find out why the simulation fails with Ruby
enabled..
Any ideas?
Thanks,
Hanmin
Design Automation Laboratory, Seoul National University
TEL +82-2-880-1787
EMAIL [email protected]
Hanmin Park
_______________________________________________
gem5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
