Anyone know why I might get different behavior when I run some workload after m5 checkpoint, and run the same workload after resuming from that checkpoint?
I do something like the following... start gem5: $> build/X86/gem5.fast /home/gedare/work/gem5/gem5/configs/example/fs.py --checkpoint-dir=/home/gedare/work/gem5/builds/hwds/m5out/1core-Java-7 --kernel=/home/gedare/work/linux/linux-2.6.28.4-gem5/vmlinux-2.6.28.4-8 --disk-image=/dist/m5/system/disks/linux-x86.img in m5term terminal: <boot linux> Script from M5 readfile is empty, starting bash shell... (none) / # m5 checkpoint (none) / # . setenv (none) / # java -classpath * -Xms256M -Xmx256M -Djava.library.path=. MyJavaApplication <output as expected, MyJavaApplication works, yay) Then I do it again... $> build/X86/gem5.fast /home/gedare/work/gem5/gem5/configs/example/fs.py --checkpoint-dir=/home/gedare/work/gem5/builds/hwds/m5out/1core-Java-7 -r 1 in m5term terminal: ==== m5 slave terminal: Terminal 0 ==== (none) / # . setenv (none) / # java -classpath * -Xms256M -Xmx256M -Djava.library.path=. MyJavaApplication <different output, with a runtime crash NoClassDefFoundError> One thought I had is the disk size might be off, perhaps some filesystem corruption occurs while restoring from the checkpointed state. Anyone have other ideas? FWIW I'm using a modfied gem5-devel from back in October. It was working fine about 2 weeks ago, and I had to get it working again, and something broke. I almost wonder if there is some updated software on my host OS that gets used by gem5 to deal with checkpoints that could cause problems? Does gem5 use something like qemu-img to read/write the COW images? -Gedare _______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
