gem5/tests/quick/fs/10.linux-boot/ref/alpha/linux/tsunami-simple-timing-dual/simout

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

gem5 compiled Feb 29 2016 18:59:12
gem5 started Feb 29 2016 18:59:20
gem5 executing on redacted.arm.com, pid 18325
command line: build/ALPHA/gem5.opt -d build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-timing-dual -re /z/atgutier/gem5/gem5-commit/tests/run.py build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-timing-dual

Global frequency set at 1000000000000 ticks per second
info: kernel located at: /dist/m5/system/binaries/vmlinux
      0: system.tsunami.io.rtc: Real-time clock set to Thu Jan  1 00:00:00 2009
info: Entering event queue @ 0.  Starting simulation...
info: Launching CPU 1 @ 881785000
Exiting @ tick 1982592736000 because m5_exit instruction encountered
stats: Update stats for final tick and memory bandwidth patches 2012-01-25 18:19:50 +01:00			`gem5 Simulator System. http://gem5.org`
			`gem5 is copyrighted software; use the --copyright option for details.`
Update ref stats. tests/test1/ref/alpha/atomic/stdout: tests/test1/ref/alpha/detailed/stderr: tests/test1/ref/alpha/detailed/stdout: tests/test1/ref/alpha/timing/stdout: Updated output. --HG-- extra : convert_revision : 3189564725ac4d2b3d63e6a71151a52326f8d416 2006-07-27 23:47:43 +02:00
cpu: Fix LLSC atomic CPU wakeup Writes to locked memory addresses (LLSC) did not wake up the locking CPU. This can lead to deadlocks on multi-core runs. In AtomicSimpleCPU, recvAtomicSnoop was checking if the incoming packet was an invalidation (isInvalidate) and only then handled a locked snoop. But, writes are seen instead of invalidates when running without caches (fast-forward configurations). As as simple fix, now handleLockedSnoop is also called even if the incoming snoop packet are from writes. 2015-07-19 22:03:30 +02:00			`gem5 compiled Feb 29 2016 18:59:12`
			`gem5 started Feb 29 2016 18:59:20`
			`gem5 executing on redacted.arm.com, pid 18325`
stats: update stats to after GPU checkin 2016-01-22 16:42:13 +01:00			`command line: build/ALPHA/gem5.opt -d build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-timing-dual -re /z/atgutier/gem5/gem5-commit/tests/run.py build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-timing-dual`
stats: updates due to recent chagnesets 2015-11-16 12:08:57 +01:00
update all the regresstion tests for release --HG-- extra : convert_revision : 47e420b5b27e196a6e7a6424540923623bb3c4d2 2007-05-16 01:25:35 +02:00			`Global frequency set at 1000000000000 ticks per second`
stats: bump stats to reflect ruby tester changes 2015-12-12 23:27:38 +01:00			`info: kernel located at: /dist/m5/system/binaries/vmlinux`
stats: update stats for icache change not allowing dirty data 2012-07-27 22:08:05 +02:00			`0: system.tsunami.io.rtc: Real-time clock set to Thu Jan 1 00:00:00 2009`
Reference updates. Since split cache is gone, a lot of config.ini changes, and minor changes to stats that are likely due to the decoupling of insertions/evictions in the cache. 2008-11-06 17:11:42 +01:00			`info: Entering event queue @ 0. Starting simulation...`
stats: updates due to recent chagnesets 2015-11-16 12:08:57 +01:00			`info: Launching CPU 1 @ 881785000`
cpu: Fix LLSC atomic CPU wakeup Writes to locked memory addresses (LLSC) did not wake up the locking CPU. This can lead to deadlocks on multi-core runs. In AtomicSimpleCPU, recvAtomicSnoop was checking if the incoming packet was an invalidation (isInvalidate) and only then handled a locked snoop. But, writes are seen instead of invalidates when running without caches (fast-forward configurations). As as simple fix, now handleLockedSnoop is also called even if the incoming snoop packet are from writes. 2015-07-19 22:03:30 +02:00			`Exiting @ tick 1982592736000 because m5_exit instruction encountered`