Changeset 11169:0a83a8d08c9e
---------------------------
ruby: Fix block_on behavior

Ruby's controller block_on behavior aimed to block MessageBuffer requests into
SLICC controllers when a Locked_RMW was in flight. Unfortunately, this
functionality only partially works: When non-Locked_RMW memory accesses are
issued to the sequencer to an address with an in-flight Locked_RMW, the
sequencer may pass those accesses through to the controller. At the controller,
a number of incorrect activities can occur depending on the protocol. In
MOESI_hammer, for example, an intermediate IFETCH will cause an L1D to L2
transfer, which cannot be serviced, because the block_on functionality blocks
the trigger queue, resulting in a deadlock. Further, if an intermediate store
arrives (e.g. from a separate SMT thread), the sequencer allows the request
through to the controller, and the atomicity of the Locked_RMW may be broken.

To avoid these problems, disallow the Sequencer from passing any memory
accesses to the controller besides Locked_RMW_Write when a Locked_RMW is in-
flight.

Considered many other potential solutions on gem5-gpu email list, which seem

unlikely to function as desired:

https://groups.google.com/forum/#!topic/gem5-gpu-dev/RQv4SxIKv7g
Found reproducible version of the IFETCH bug with gem5 11139:bd894d2bdd7c (using the xsave disable patch in this email thread:  http://comments.gmane.org/gmane.comp.emulators.m5.devel/24558 )
Reproducible command line: ../build/X86_MOESI_hammer/gem5.opt --outdir=$outdir ../configs/example/fs.py --ruby --cpu-type=detailed --caches --num-cpus=4 --script ../configs/boot/hack_back_ckpt.rcS --kernel ../../full_system_files/binaries/x86_64-vmlinux-2.6.28.4-smp
Verified that the patch fixes the reproducible bug and tested that booting

Linux works with O3CPU and numerous other system configurations.