----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3149/ -----------------------------------------------------------
Review request for Default. Repository: gem5 Description ------- Changeset 11157:65d87638830f --------------------------- 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. Diffs ----- src/mem/ruby/slicc_interface/AbstractController.hh bd894d2bdd7c src/mem/ruby/slicc_interface/AbstractController.cc bd894d2bdd7c src/mem/ruby/system/Sequencer.cc bd894d2bdd7c Diff: http://reviews.gem5.org/r/3149/diff/ Testing ------- 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. Thanks, Joel Hestness _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
