----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2074/ -----------------------------------------------------------
(Updated Oct. 30, 2013, 1:47 p.m.) Review request for Default. Summary (updated) ----------------- ruby: Fixed a deadlock when restoring a checkpoint with garnet Repository: gem5 Description ------- 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. Diffs ----- src/mem/ruby/network/garnet/fixed-pipeline/SWallocator_d.cc cd0a9c975c8c src/mem/ruby/network/garnet/fixed-pipeline/VCallocator_d.cc cd0a9c975c8c Diff: http://reviews.gem5.org/r/2074/diff/ Testing ------- 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 Thanks, Emilio Castillo _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
