Hi Jack, People generally don't make checkpoints with the detailed CPU as the cache state isn't saved, and thus you can't restore from the checkpoint (any dirty lines would be thrown away). It would be possible to either checkpoint the dirty state in the caches, or write back the dirty data into the physmem image when a checkpoint is created, but it's not done. That said, it shouldn't segfault when you try. Can you look at a backtrace of when it happens and see if you can figure out where the null pointer is coming from?
Thanks, Ali On Jan 11, 2012, at 5:00 AM, Jack Harvard wrote: > A plain built of ARM_SE gem5.opt from the gem5 repo, then make > checkpoints in the detailed O3 CPU mode with L1 and L2 caches > (although the usual case is to make checkpoints with atomic mode which > works) > > build/ARM_SE/gem5.opt configs/example/se.py --caches --l2cache > --cpu-type=detailed --checkpoint-dir=./m5out/checkpoint/ > --take-checkpoints 14030000,5000 --max-checkpoints 1 > > The command manifests with the following segmentation fault. > > Program received signal SIGSEGV, Segmentation fault. > ArmISA::copyRegs (src=0x26e9900, dest=0x2a8d310) at > build/ARM_SE/arch/arm/utility.cc:154 > 154 dest->getITBPtr()->invalidateMiscReg(); > > Jack Harvard > _______________________________________________ > gem5-users mailing list > [email protected] > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users > _______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
