gem5-users@gem5.org

The gem5 Users mailing list

View all threads

Problem with gem5 FS-mode and parsec

SW
Stephan Walter
Fri, Sep 16, 2011 4:59 PM

Hi,

i try to use gem5 for a small project at the university. Since 4 weeks
i try to run parsec on gem5, but i am not abel to do this.

Ok first what i have done.

A: Download gem5.tarball -> ok no good idea...
B: get the gem5.stable repository from the server with mercurial
C: get the FS-files from the gem5 download page
D: get the Parsec-2.1 disk img, .rcS Script and the Linux 2.6.27
kernel img from http://www.cs.utexas.edu/~parsec_m5/
E: follow the instruction in the manual for the parsec benchmarks. Now
there is my first problem. The kernel.org page is offline. I think
this is not a problem, because of the linux 2.6.27 kernel. I think it
is compiled etc. so i just renamed the vmlinux....2.6.27 file into
vmlinux and replace the vmlinux file from the FS-file package.

Now i think every thing should work, but when i try to compile gem5 with

scons /build/ALPHA_FS/

a lot of seltests failed.

For example this one:

diff -ubrs -I '^command line:' -I '^M5 compiled ' -I '^M5 started ' -I
'^M5 executing on ' -I '^Simulation complete at' -I '^Listening for'
-I 'listening for remote gdb' --exclude=stats.txt --exclude=outdiff
tests/long/10.linux-boot/ref/alpha/linux/tsunami-o3
build/ALPHA_FS/tests/debug/long/10.linux-boot/alpha/linux/tsunami-o3 >
build/ALPHA_FS/tests/debug/long/10.linux-boot/alpha/linux/tsunami-o3/outdiff
scons: *** Error 1
===== Output differences =====
diff -ubrs -I '^command line:' -I '^M5 compiled ' -I '^M5 started ' -I
'^M5 executing on ' -I '^Simulation complete at' -I '^Listening for'
-I 'listening for remote gdb' '--exclude=stats.txt'
'--exclude=outdiff'
tests/long/10.linux-boot/ref/alpha/linux/tsunami-o3/config.ini
build/ALPHA_FS/tests/debug/long/10.linux-boot/alpha/linux/tsunami-o3/config.ini

tests/long/10.linux-boot/ref/alpha/linux/tsunami-o3/config.ini 2011-09-09
16:49:08.108057289 +0200
+++
build/ALPHA_FS/tests/debug/long/10.linux-boot/alpha/linux/tsunami-o3/config.ini 2011-09-16 16:54:59.957208352
+0200
@@ -10,12 +10,12 @@
children=bridge cpu disk0 disk2 intrctrl iobus iocache l2c membus
physmem simple_disk terminal toL2Bus tsunami
boot_cpu_frequency=500

here the simerr file:

warn: Sockets disabled, not accepting terminal connections
warn: Sockets disabled, not accepting gdb connections
warn: Prefetch instrutions is Alpha do not do anything
warn: Prefetch instrutions is Alpha do not do anything
hack: be nice to actually delete the event here

summary:


build/ALPHA_FS/tests/fast/quick/80.netperf-stream/alpha/linux/twosys-tsunami-simple-atomic
FAILED!


build/ALPHA_FS/tests/opt/long/10.linux-boot/alpha/linux/tsunami-o3
FAILED!


build/ALPHA_FS/tests/opt/long/10.linux-boot/alpha/linux/tsunami-o3-dual
FAILED!


build/ALPHA_FS/tests/opt/quick/10.linux-boot/alpha/linux/tsunami-simple-atomic
FAILED!


build/ALPHA_FS/tests/opt/quick/10.linux-boot/alpha/linux/tsunami-simple-atomic-dual
FAILED!


build/ALPHA_FS/tests/opt/quick/10.linux-boot/alpha/linux/tsunami-simple-timing
FAILED!


build/ALPHA_FS/tests/opt/quick/10.linux-boot/alpha/linux/tsunami-simple-timing-dual
FAILED!


build/ALPHA_FS/tests/opt/quick/80.netperf-stream/alpha/linux/twosys-tsunami-simple-atomic
FAILED!

It also the tests take very long time, some hours.

I tried hard, so solve the problem by my self, but now i have no more
ideas, how to solve the problem.

By the way, when i try to boot linux i get this output:

$ ./build/ALPHA_FS/m5.debug configs/example/fs.py

gem5 Simulator System.  http://gem5.org
gem5 is copyrighted software; use the --copyright option for details.

gem5 compiled Sep 16 2011 16:35:24
gem5 started Sep 16 2011 18:56:54
gem5 executing on hollerith
command line: ./build/ALPHA_FS/m5.debug configs/example/fs.py
Global frequency set at 1000000000000 ticks per second
info: kernel located at: /gem5_rep/binaries/vmlinux
Listening for system connection on port 3456
0: system.tsunami.io.rtc: Real-time clock set to Thu Jan  1
00:00:00 2009
0: system.remote_gdb.listener: listening for remote gdb #0 on port 7000
**** REAL SIMULATION ****
info: Entering event queue @ 0.  Starting simulation...
warn: Prefetch instrutions is Alpha do not do anything
warn: Prefetch instrutions is Alpha do not do anything

after that nothing happens for 20h+

I think it is broken.

Thank you very much for your help.

Stephan Walter

Hi, i try to use gem5 for a small project at the university. Since 4 weeks i try to run parsec on gem5, but i am not abel to do this. Ok first what i have done. A: Download gem5.tarball -> ok no good idea... B: get the gem5.stable repository from the server with mercurial C: get the FS-files from the gem5 download page D: get the Parsec-2.1 disk img, .rcS Script and the Linux 2.6.27 kernel img from http://www.cs.utexas.edu/~parsec_m5/ E: follow the instruction in the manual for the parsec benchmarks. Now there is my first problem. The kernel.org page is offline. I think this is not a problem, because of the linux 2.6.27 kernel. I think it is compiled etc. so i just renamed the vmlinux....2.6.27 file into vmlinux and replace the vmlinux file from the FS-file package. Now i think every thing should work, but when i try to compile gem5 with scons /build/ALPHA_FS/ a lot of seltests failed. For example this one: diff -ubrs -I '^command line:' -I '^M5 compiled ' -I '^M5 started ' -I '^M5 executing on ' -I '^Simulation complete at' -I '^Listening for' -I 'listening for remote gdb' --exclude=stats.txt --exclude=outdiff tests/long/10.linux-boot/ref/alpha/linux/tsunami-o3 build/ALPHA_FS/tests/debug/long/10.linux-boot/alpha/linux/tsunami-o3 > build/ALPHA_FS/tests/debug/long/10.linux-boot/alpha/linux/tsunami-o3/outdiff scons: *** Error 1 ===== Output differences ===== diff -ubrs -I '^command line:' -I '^M5 compiled ' -I '^M5 started ' -I '^M5 executing on ' -I '^Simulation complete at' -I '^Listening for' -I 'listening for remote gdb' '--exclude=stats.txt' '--exclude=outdiff' tests/long/10.linux-boot/ref/alpha/linux/tsunami-o3/config.ini build/ALPHA_FS/tests/debug/long/10.linux-boot/alpha/linux/tsunami-o3/config.ini --- tests/long/10.linux-boot/ref/alpha/linux/tsunami-o3/config.ini 2011-09-09 16:49:08.108057289 +0200 +++ build/ALPHA_FS/tests/debug/long/10.linux-boot/alpha/linux/tsunami-o3/config.ini 2011-09-16 16:54:59.957208352 +0200 @@ -10,12 +10,12 @@ children=bridge cpu disk0 disk2 intrctrl iobus iocache l2c membus physmem simple_disk terminal toL2Bus tsunami boot_cpu_frequency=500 here the simerr file: warn: Sockets disabled, not accepting terminal connections warn: Sockets disabled, not accepting gdb connections warn: Prefetch instrutions is Alpha do not do anything warn: Prefetch instrutions is Alpha do not do anything hack: be nice to actually delete the event here summary: ***** build/ALPHA_FS/tests/fast/quick/80.netperf-stream/alpha/linux/twosys-tsunami-simple-atomic FAILED! ***** build/ALPHA_FS/tests/opt/long/10.linux-boot/alpha/linux/tsunami-o3 FAILED! ***** build/ALPHA_FS/tests/opt/long/10.linux-boot/alpha/linux/tsunami-o3-dual FAILED! ***** build/ALPHA_FS/tests/opt/quick/10.linux-boot/alpha/linux/tsunami-simple-atomic FAILED! ***** build/ALPHA_FS/tests/opt/quick/10.linux-boot/alpha/linux/tsunami-simple-atomic-dual FAILED! ***** build/ALPHA_FS/tests/opt/quick/10.linux-boot/alpha/linux/tsunami-simple-timing FAILED! ***** build/ALPHA_FS/tests/opt/quick/10.linux-boot/alpha/linux/tsunami-simple-timing-dual FAILED! ***** build/ALPHA_FS/tests/opt/quick/80.netperf-stream/alpha/linux/twosys-tsunami-simple-atomic FAILED! It also the tests take very long time, some hours. I tried hard, so solve the problem by my self, but now i have no more ideas, how to solve the problem. By the way, when i try to boot linux i get this output: $ ./build/ALPHA_FS/m5.debug configs/example/fs.py gem5 Simulator System. http://gem5.org gem5 is copyrighted software; use the --copyright option for details. gem5 compiled Sep 16 2011 16:35:24 gem5 started Sep 16 2011 18:56:54 gem5 executing on hollerith command line: ./build/ALPHA_FS/m5.debug configs/example/fs.py Global frequency set at 1000000000000 ticks per second info: kernel located at: /gem5_rep/binaries/vmlinux Listening for system connection on port 3456 0: system.tsunami.io.rtc: Real-time clock set to Thu Jan 1 00:00:00 2009 0: system.remote_gdb.listener: listening for remote gdb #0 on port 7000 **** REAL SIMULATION **** info: Entering event queue @ 0. Starting simulation... warn: Prefetch instrutions is Alpha do not do anything warn: Prefetch instrutions is Alpha do not do anything after that nothing happens for 20h+ I think it is broken. Thank you very much for your help. Stephan Walter
GM
Gabriel Michael Black
Sat, Sep 17, 2011 11:50 PM

A lot of the regression tests require you to have binaries that we
aren't allowed to distribute because of how they're licensed (part of
benchmark suites, for instance). Those tests will fail unless you have
our particular binaries because the tests are very picky, expecting
exactly a certain number of instructions to be executed with exactly
the right statistics as far as branch prediction, cache behavior, etc.
It's extremely unlikely that you would be able to generate those
binaries yourself in such a way that the tests will fail. If that's
what the problem is, then everything is actually fine. If the hello
world test works then you're probably ok. This is a recognized and
regularly commented on deficiency in our testing framework, and one of
these days we're going to fix it.

If you use fs.py, you don't have to (or at least shouldn't have to)
rename your binaries. You can use arguments to the script to change
what files it looks for.

If you want to see output from the console, you should use the m5term
program to connect to the system's simulated serial port. In FS mode,
the system doesn't print anything to the console you run it from. All
the output is directed over the simulated serial device like it would
be (or at least could be) in a real system. There should be
instructions on how to do that on the wiki.

I'm not that familiar with how the Parsec stuff is set up to work, but
if it's actually running the benchmarks it could take a really long
time. Simulated time passes much slower than real time when the
simulated system is actually doing something. I'd recommend you use
gem5.opt. It behaves basically the same, it just has optimization
turned on in gcc which can make a big difference. If something is
breaking and you're trying to debug the gem5 binary with gdb,
valgrind, etc., then gem5.debug might be the better choice since
functions won't be inlined, variables won't be optimized away, etc.,
but for running normally gem5.opt is a lot better.

Gabe

Quoting Stephan Walter <swalter(a)ix.urz.uni-heidelberg.de>:

Hi,

i try to use gem5 for a small project at the university. Since 4
weeks i try to run parsec on gem5, but i am not abel to do this.

Ok first what i have done.

A: Download gem5.tarball -> ok no good idea...
B: get the gem5.stable repository from the server with mercurial
C: get the FS-files from the gem5 download page
D: get the Parsec-2.1 disk img, .rcS Script and the Linux 2.6.27
kernel img from http://www.cs.utexas.edu/~parsec_m5/
E: follow the instruction in the manual for the parsec benchmarks.
Now there is my first problem. The kernel.org page is offline. I
think this is not a problem, because of the linux 2.6.27 kernel. I
think it is compiled etc. so i just renamed the vmlinux....2.6.27
file into vmlinux and replace the vmlinux file from the FS-file
package.

Now i think every thing should work, but when i try to compile gem5 with

scons /build/ALPHA_FS/

a lot of seltests failed.

For example this one:

diff -ubrs -I '^command line:' -I '^M5 compiled ' -I '^M5 started '
-I '^M5 executing on ' -I '^Simulation complete at' -I '^Listening
for' -I 'listening for remote gdb' --exclude=stats.txt
--exclude=outdiff
tests/long/10.linux-boot/ref/alpha/linux/tsunami-o3
build/ALPHA_FS/tests/debug/long/10.linux-boot/alpha/linux/tsunami-o3

build/ALPHA_FS/tests/debug/long/10.linux-boot/alpha/linux/tsunami-o3/outdiff
scons: *** Error 1
===== Output differences =====
diff -ubrs -I '^command line:' -I '^M5 compiled ' -I '^M5 started '
-I '^M5 executing on ' -I '^Simulation complete at' -I '^Listening
for' -I 'listening for remote gdb' '--exclude=stats.txt'
'--exclude=outdiff'
tests/long/10.linux-boot/ref/alpha/linux/tsunami-o3/config.ini
build/ALPHA_FS/tests/debug/long/10.linux-boot/alpha/linux/tsunami-o3/config.ini

tests/long/10.linux-boot/ref/alpha/linux/tsunami-o3/config.ini 2011-09-09
16:49:08.108057289 +0200
+++
build/ALPHA_FS/tests/debug/long/10.linux-boot/alpha/linux/tsunami-o3/config.ini 2011-09-16 16:54:59.957208352
+0200
@@ -10,12 +10,12 @@
children=bridge cpu disk0 disk2 intrctrl iobus iocache l2c membus
physmem simple_disk terminal toL2Bus tsunami
boot_cpu_frequency=500

here the simerr file:

warn: Sockets disabled, not accepting terminal connections
warn: Sockets disabled, not accepting gdb connections
warn: Prefetch instrutions is Alpha do not do anything
warn: Prefetch instrutions is Alpha do not do anything
hack: be nice to actually delete the event here

summary:


build/ALPHA_FS/tests/fast/quick/80.netperf-stream/alpha/linux/twosys-tsunami-simple-atomic
FAILED!


build/ALPHA_FS/tests/opt/long/10.linux-boot/alpha/linux/tsunami-o3
FAILED!


build/ALPHA_FS/tests/opt/long/10.linux-boot/alpha/linux/tsunami-o3-dual
FAILED!


build/ALPHA_FS/tests/opt/quick/10.linux-boot/alpha/linux/tsunami-simple-atomic
FAILED!


build/ALPHA_FS/tests/opt/quick/10.linux-boot/alpha/linux/tsunami-simple-atomic-dual
FAILED!


build/ALPHA_FS/tests/opt/quick/10.linux-boot/alpha/linux/tsunami-simple-timing
FAILED!


build/ALPHA_FS/tests/opt/quick/10.linux-boot/alpha/linux/tsunami-simple-timing-dual
FAILED!


build/ALPHA_FS/tests/opt/quick/80.netperf-stream/alpha/linux/twosys-tsunami-simple-atomic
FAILED!

It also the tests take very long time, some hours.

I tried hard, so solve the problem by my self, but now i have no
more ideas, how to solve the problem.

By the way, when i try to boot linux i get this output:

$ ./build/ALPHA_FS/m5.debug configs/example/fs.py

gem5 Simulator System.  http://gem5.org
gem5 is copyrighted software; use the --copyright option for details.

gem5 compiled Sep 16 2011 16:35:24
gem5 started Sep 16 2011 18:56:54
gem5 executing on hollerith
command line: ./build/ALPHA_FS/m5.debug configs/example/fs.py
Global frequency set at 1000000000000 ticks per second
info: kernel located at: /gem5_rep/binaries/vmlinux
Listening for system connection on port 3456
0: system.tsunami.io.rtc: Real-time clock set to Thu Jan  1
00:00:00 2009
0: system.remote_gdb.listener: listening for remote gdb #0 on port 7000
**** REAL SIMULATION ****
info: Entering event queue @ 0.  Starting simulation...
warn: Prefetch instrutions is Alpha do not do anything
warn: Prefetch instrutions is Alpha do not do anything

after that nothing happens for 20h+

I think it is broken.

Thank you very much for your help.

Stephan Walter


gem5-users mailing list
gem5-users(a)gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

A lot of the regression tests require you to have binaries that we aren't allowed to distribute because of how they're licensed (part of benchmark suites, for instance). Those tests will fail unless you have our particular binaries because the tests are very picky, expecting exactly a certain number of instructions to be executed with exactly the right statistics as far as branch prediction, cache behavior, etc. It's *extremely* unlikely that you would be able to generate those binaries yourself in such a way that the tests will fail. If that's what the problem is, then everything is actually fine. If the hello world test works then you're probably ok. This is a recognized and regularly commented on deficiency in our testing framework, and one of these days we're going to fix it. If you use fs.py, you don't have to (or at least shouldn't have to) rename your binaries. You can use arguments to the script to change what files it looks for. If you want to see output from the console, you should use the m5term program to connect to the system's simulated serial port. In FS mode, the system doesn't print anything to the console you run it from. All the output is directed over the simulated serial device like it would be (or at least could be) in a real system. There should be instructions on how to do that on the wiki. I'm not that familiar with how the Parsec stuff is set up to work, but if it's actually running the benchmarks it could take a really long time. Simulated time passes much slower than real time when the simulated system is actually doing something. I'd recommend you use gem5.opt. It behaves basically the same, it just has optimization turned on in gcc which can make a big difference. If something is breaking and you're trying to debug the gem5 binary with gdb, valgrind, etc., then gem5.debug might be the better choice since functions won't be inlined, variables won't be optimized away, etc., but for running normally gem5.opt is a lot better. Gabe Quoting Stephan Walter <swalter(a)ix.urz.uni-heidelberg.de>: > Hi, > > i try to use gem5 for a small project at the university. Since 4 > weeks i try to run parsec on gem5, but i am not abel to do this. > > Ok first what i have done. > > A: Download gem5.tarball -> ok no good idea... > B: get the gem5.stable repository from the server with mercurial > C: get the FS-files from the gem5 download page > D: get the Parsec-2.1 disk img, .rcS Script and the Linux 2.6.27 > kernel img from http://www.cs.utexas.edu/~parsec_m5/ > E: follow the instruction in the manual for the parsec benchmarks. > Now there is my first problem. The kernel.org page is offline. I > think this is not a problem, because of the linux 2.6.27 kernel. I > think it is compiled etc. so i just renamed the vmlinux....2.6.27 > file into vmlinux and replace the vmlinux file from the FS-file > package. > > Now i think every thing should work, but when i try to compile gem5 with > > scons /build/ALPHA_FS/ > > a lot of seltests failed. > > For example this one: > > diff -ubrs -I '^command line:' -I '^M5 compiled ' -I '^M5 started ' > -I '^M5 executing on ' -I '^Simulation complete at' -I '^Listening > for' -I 'listening for remote gdb' --exclude=stats.txt > --exclude=outdiff > tests/long/10.linux-boot/ref/alpha/linux/tsunami-o3 > build/ALPHA_FS/tests/debug/long/10.linux-boot/alpha/linux/tsunami-o3 > > > build/ALPHA_FS/tests/debug/long/10.linux-boot/alpha/linux/tsunami-o3/outdiff > scons: *** Error 1 > ===== Output differences ===== > diff -ubrs -I '^command line:' -I '^M5 compiled ' -I '^M5 started ' > -I '^M5 executing on ' -I '^Simulation complete at' -I '^Listening > for' -I 'listening for remote gdb' '--exclude=stats.txt' > '--exclude=outdiff' > tests/long/10.linux-boot/ref/alpha/linux/tsunami-o3/config.ini > build/ALPHA_FS/tests/debug/long/10.linux-boot/alpha/linux/tsunami-o3/config.ini > --- > tests/long/10.linux-boot/ref/alpha/linux/tsunami-o3/config.ini 2011-09-09 > 16:49:08.108057289 +0200 > +++ > build/ALPHA_FS/tests/debug/long/10.linux-boot/alpha/linux/tsunami-o3/config.ini 2011-09-16 16:54:59.957208352 > +0200 > @@ -10,12 +10,12 @@ > children=bridge cpu disk0 disk2 intrctrl iobus iocache l2c membus > physmem simple_disk terminal toL2Bus tsunami > boot_cpu_frequency=500 > > here the simerr file: > > warn: Sockets disabled, not accepting terminal connections > warn: Sockets disabled, not accepting gdb connections > warn: Prefetch instrutions is Alpha do not do anything > warn: Prefetch instrutions is Alpha do not do anything > hack: be nice to actually delete the event here > > > > summary: > ***** > build/ALPHA_FS/tests/fast/quick/80.netperf-stream/alpha/linux/twosys-tsunami-simple-atomic > FAILED! > > ***** > build/ALPHA_FS/tests/opt/long/10.linux-boot/alpha/linux/tsunami-o3 > FAILED! > > ***** > build/ALPHA_FS/tests/opt/long/10.linux-boot/alpha/linux/tsunami-o3-dual > FAILED! > > ***** > build/ALPHA_FS/tests/opt/quick/10.linux-boot/alpha/linux/tsunami-simple-atomic > FAILED! > > ***** > build/ALPHA_FS/tests/opt/quick/10.linux-boot/alpha/linux/tsunami-simple-atomic-dual > FAILED! > > ***** > build/ALPHA_FS/tests/opt/quick/10.linux-boot/alpha/linux/tsunami-simple-timing > FAILED! > > ***** > build/ALPHA_FS/tests/opt/quick/10.linux-boot/alpha/linux/tsunami-simple-timing-dual > FAILED! > > ***** > build/ALPHA_FS/tests/opt/quick/80.netperf-stream/alpha/linux/twosys-tsunami-simple-atomic > FAILED! > > It also the tests take very long time, some hours. > > I tried hard, so solve the problem by my self, but now i have no > more ideas, how to solve the problem. > > > > By the way, when i try to boot linux i get this output: > > $ ./build/ALPHA_FS/m5.debug configs/example/fs.py > > gem5 Simulator System. http://gem5.org > gem5 is copyrighted software; use the --copyright option for details. > > gem5 compiled Sep 16 2011 16:35:24 > gem5 started Sep 16 2011 18:56:54 > gem5 executing on hollerith > command line: ./build/ALPHA_FS/m5.debug configs/example/fs.py > Global frequency set at 1000000000000 ticks per second > info: kernel located at: /gem5_rep/binaries/vmlinux > Listening for system connection on port 3456 > 0: system.tsunami.io.rtc: Real-time clock set to Thu Jan 1 > 00:00:00 2009 > 0: system.remote_gdb.listener: listening for remote gdb #0 on port 7000 > **** REAL SIMULATION **** > info: Entering event queue @ 0. Starting simulation... > warn: Prefetch instrutions is Alpha do not do anything > warn: Prefetch instrutions is Alpha do not do anything > > after that nothing happens for 20h+ > > I think it is broken. > > Thank you very much for your help. > > Stephan Walter > > > _______________________________________________ > gem5-users mailing list > gem5-users(a)gem5.org > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >