The backticked (`...`) pip install command in the error messages was
being parsed by the shell script as a command to run when printed. This
fixes the problem by replacing the backticks with single-quotes.
Change-Id: Ib97f6cf9f8bd0eb8bc1beae70efd5277bb51544d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/63011
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Once the switch node in a dist-gem5 simulation gets started it listens
the first available port starting from the initially supplied one.
To bind full system nodes to the switch, the switch logfile
is parsed for the exact port number.
This is fragile and it broke when the following line:
info: tcp_iface listening on port
changed to
build/ARM/dev/net/tcp_iface.cc:97: info: tcp_iface listening on port
This patch is fixing the problem with a more robust regex matching
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Change-Id: I2721b3c04653ac1e09878e80d8b1ea34ec1a0f73
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/62512
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Richard Cooper <richard.cooper@arm.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Prior to this patch those building from these Dockerfiles could
encounter caching issues where the `apt -y update` RUN was loaded from a
cached layer prior to running the `install` command. Typically this was
trying to obtain a package from a wrong IP address. The fix for this is
to run this all in one Docker RUN to avoid loading a broken cache.
Change-Id: If309c5c1d4a0240fed670abe980772d90f7d2172
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/59350
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
In order to compile binaries to run in GPUFS, users would either have to
install ROCm 4.2 locally, use something like docker, or build within
gem5 using KVM and copy the binary out. The simplest way of those is to
use docker. This minimal dockerfile contains only ROCm 4.2 and can build
binaries that will be placed on the host which can be run in gem5.
For example, current gem5-resources can be built for gem5 as follows:
cd util/dockerfiles/gpu-fs
docker build -t rocm42-build .
cd /path/to/gem5-resources/src/gpu/hip-samples
docker run --rm -u $UID:$GID -v ${PWD}:${PWD} \
-w ${PWD} rocm42-build make
Those binaries can then be run in gem5 using the
configs/example/gpufs/vega10_kvm.py script:
build/VEGA_X86/gem5.opt configs/example/gpufs/vega10_kvm.py --app \
/path/to/gem5-resources/src/gpu/hip-samples/bin/MatrixTranspose
Change-Id: Ie76146be0ccf6fcc1941322cacc15965fe70073a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/59051
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This change replaces and removes the out-of-date APIs to fix the build
error, and add fixClockFrequency() call to fix the runtime error. We
also need the TRACING_ON macro and C++17 to build because of the
header changes.
Tested with X86 and tests/test-progs/hello. Checkpoint restore is not
tested yet.
Change-Id: Id92bb7954defea15b026eba3229a453b688929be
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/58989
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This is a useful script for quickly checking the hash values of
resources. Since this uses the same function as the downloader, using
this utility ensures the values are identical to that found in
resources.json (i.e., what the downloader checks against to see if a
resource has changed).
Change-Id: I37f39cb8fd2c92725d956170b3656cbfb4480ce6
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/58850
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The "util/cloudbuild" directory was used to build Docker images on
the Google Cloud Build infrastructure. The gem5 project no longer uses
this service to build Docker images and, as such, this directory (and
its contents) are no longer required.
Change-Id: I724c50ec6045ab95f6b94533f2fd54980230789c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/57431
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
"docker-compose.yaml" is used by the docker-compose utility to define
Docker image builds. In the case the "docker-compose.yaml" file defines
the building of all Docker images used in the gem5 project. These can be
built locally using `docker-compose build`.
Change-Id: I2544ec43e3a1743884e5aa243905704cb263d7d9
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/57429
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
rocBLAS builds for all targets by default, but it requires we set the
HCC_AMDGPU_TARGET env variable to all the targets we want to build for.
This change explicitly sets all the gfx versions we intend to support in
gem5, and removes the extraneous "-a all" from the install command.
Additionally, doing this allowed for DNNMark to run on gfx902.
Change-Id: Id1a00433beaa23f6935c12073d5bddc38431886b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/54623
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Reviewed-by: Matthew Poremba <matthew.poremba@amd.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Remove the line "For use for simulation and test purposes only" in files
were AMD is the only copyright holder listed in the header. This happens
to be the case for all files where this line exists, removing it
completely from gem5.
Change-Id: I623f266b002f564301b28774f49081099cfc60fd
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/53943
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This test includes,
- A dockerfile creating a Docker image containing SST-Core
and SST-Elements installed. The image also contains the
bbl-busybox-boot-exit binary from gem5-resources.
- A nightly test involving compiling gem5 as a library, and
booting a linux kernel without a disk image using SST where
gem5 TimingSimpleCPU is the CPU core.
Change-Id: I2bf90b4121ed0d38300451648f2e358a7c3fffe2
Signed-off-by: Hoa Nguyen <hoanguyen@ucdavis.edu>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52564
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Currently, if a maintainer is removed from a change, the maintainer
will be added again. This change prevents the bot from adding the
removed maintainer again.
The bot will query all updates related to reviewer addition/removal
for each new change. If a reviewer has ever been added/removed
from a change, that reviewer won't be added to that change again.
Change-Id: Ifaab5ebd7ebf3e6453b2551d3e37c1b9e214c906
Signed-off-by: Hoa Nguyen <hoanguyen@ucdavis.edu>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/50187
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
In the gcn-gpu image, rocBLAS wasn't able to be installed. This was
due to us not installing rocm-cmake, as rocBLAS is dependent on it
and will download the most recent version of rocm-cmake if it
isn't installed. The most recent version of rocm-cmake wasn't
compatible with the version of ROCm we're using.
This patch installs rocm-cmake before building and installing
rocBLAS instead of after.
Change-Id: Iaaa34d5e0d6594fddd0d1a7d147f43405163ca89
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/50847
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
This can be built to create an image that uses the GCC-11 compiler. At
present GCC-11 cannot be installed using APT by default. This
Dockerfile uses a special APT repository to do this and is therefore a
separate Dockerfile to the other GCC version targets.
Change-Id: Iafee92415d9047eedf3586c78722f973010f6050
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/50748
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Suppress any valgrind error from *anywhere* in the libpython library.
There are ***many*** false positives in the python library, making the
output of valgrind almost useless without lots of suppressions. Rather
than suppress each error piecemeal, we can suppress any error which
originates in libpython to cover them all.
There will now be corner cases where a bug in gem5 causes some sort of
illegal access, etc, within the python library itself, but these sorts
of interactions/errors should be very rare. Suppressing the fountain of
false positives coming from libpython makes valgrind useable in general,
which IMO is a very worthwhile tradeoff.
Change-Id: I4869eeeb4aef5884ad52025b52c9616e0541f3e6
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49530
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The CXX config code is not entirely correct, and will fail with some of
the objects defined for systemc support. If you're going to build gem5
with --with-cxx-config, you have to also disable the systemc support.
This had been updated in the gem5_with_systemc/README file, but not in
the tlm/README file.
Change-Id: Icd933e867c5e51fe8725a4a2c0925c41675ce4fd
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49453
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The upgraders in util/cpt_upgraders have been able to check the
root.isa element of checkpoints to determine what "the" ISA is for a
simulation, as a quick way to bail out of that particular updater
applies only to specific ISAs. We are moving away from the idea that
there is a single ISA, and so this mechanism will no longer work.
Fortunately, these cpt_upgraders are only relevant for old checkpoints.
If a checkpoint doesn't have a root.isa element inside it at all, we
know (as of this writing) that it is newer than all of these upgraders
and hence they do not apply. Any new upgraders will have to be written
to not rely on the root.isa field which will be removed. If that sort
of field is still needed, it can be added somewhere else in the
hierarchy, perhaps at the system level, or as part of the actual ISA
object.
The simplest way to implement this new behavior is to add a fallback
option when an upgrader looks for root.isa, specifically ''. If the
root.isa element does not exist, the script will get '' back, and this
will not match whatever ISA it's trying to check against. The one even
remotely more complicated script is isa-is-simobject.py which has
several behaviors for different ISAs. In that case, we just explicitly
check for '' and return early if that's what we found.
Jira Issue: https://gem5.atlassian.net/browse/GEM5-1056
Change-Id: Ie78deccb2bac51f38224e62a28dd733cefd63ed7
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/48883
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
