ruby: Fixed a deadlock when restoring a checkpoint with garnet
Review Request #2074 - Created Oct. 30, 2013 and submitted - Latest diff uploaded
| Information | |
|---|---|
| Emilio Castillo | |
| gem5 | |
| Reviewers | |
| Default | |
This patch fixes a problem where in Garnet, the enqueue time in the VCallocator and the SWallocator which is of type Cycles was being stored inside a variable with int type. This lead to a known problem restoring checkpoints with garnet & the fixed pipeline enabled. That value was really big and didn't fit in the variable overflowing it, therefore some conditions on the VC allocation stage & the SW allocation stage were not met and the packets didn't advance through the network, leading to a deadlock panic right after the checkpoint was restored.
Originally the checkpoint was obtained in the atomic mode by doing some like this: build/X86/gem5.opt configs/example/fs.py -n 16 --script=canneal_16c_simsmall.rcS --kernel=x86_64-vmlinux-2.6.28.4-smp --disk-image=x86root.img The m5checkpoint instruction is somewhere the binary i'm executing. The checkpoint was restored with: build/X86_MESI_CMP_directory/gem5.opt configs/example/ruby_fs.py -n 16 --kernel=x86_64-vmlinux-2.6.28.4-smp --disk-image=x86root.img -r1 --num-l2cache=16 --num-dir=16 --topo=Mesh --mesh-rows=4 --restore-with=timing --garnet=fixed
