When M5 prints "thread reached the max instruction count" that means it reached the max instruction count and stopped, not that the checkpoint is ready. I'm not sure what would happen if you tried creating a checkpoint after the simulation was considered over on a particular thread.
Gabe On 03/29/11 12:13, Griffin Wright wrote: > > In what situations is checkpoint taking/restoring actually supported > in m5? > > I have tried creating and restoring checkpoints with different > programs in simple atomic, simple timing, and detailed(O3CPUTim) > modes, and they all fail due to unserialization errors somewhere, > either with system.cpu:locked, or Globals.curTick (in the case of > detailed mode). I'm not sure what I'm missing, and would at least > like some clarification on how m5 supports checkpointing in any of > these modes. I've looked at various unserialize methods, and can't > tell what functionality they might be lacking which causes these troubles. > > In all cases, once I create the checkpoint, the program exits due to a > "thread reached the max instruction count", but that doesn't concern > me because at that point, the checkpoint has become available for use. > > Thanks, > > Griffin Wright > > > > On Sun, 27 Mar 2011 12:04:53 -0500, Ali Saidi <[email protected]> wrote: > > Why are you taking checkpoints with a timing cpu and not an atomic > one? It's faster and the caches don't save their state, so if > you're using caches with the timing CPU you'll get an incomplete > checkpoint. > Ali > > On Mar 27, 2011, at 11:15 AM, Griffin Wright wrote: > > Hello, > > I'm working with checkpoints on simulations with an ARM_SE > setup on a simple timing CPU, and while I can take a > checkpoint in simple timing mode just fine, when I attempt to > restore from a checkpoint, I get the following: > > fatal: Can't unserialize 'system.cpu:locked' > @ cycle 1945913882000 > [paramIn:build/ARM_SE/sim/serialize.cc, line 211] > Memory Usage: 559288 KBytes > For more information see: http://www.m5sim.org/fatal/60de9f5a > > That link points to nothing, but that's no biggie. I skimmed > through the user's archive and found some related queries, > with the quote at the end of this message being a solution. > I'm wondering if this is in fact the only way to use the > provided restore-checkpoint feature in m5, or if progress has > been made with regards to the simple timing CPU since this > below post, or if I'm looking at my error in the wrong light > altogether. > > The code that is failing is as follows, showing that > system.cpu:locked cannot be unserialized: > > if (!cp->find(section, name, str) || !parseParam(str, > param)) { > fatal("Can't unserialize '%s:%s'\n", section, name); > } > > "Resume() is the opposite of drain() which means the > system can continue issuing requests and acting as normal. > serialize() > needs to save all of the state the CPU needs to put itself in the > same > state as it was executing and unserialize() restores that saved > state. > Looking at other implementations of save()/restore() is the easiest > way to do this. Finally, if you want to be able to switch to/from the > > inorder cpu switchOut() and takeOverFrom() need to be implemented. > > > Thank you, > Griffin Wright > > > _______________________________________________ > m5-users mailing list > [email protected] <mailto:[email protected]> > http://m5sim.org/cgi-bin/mailman/listinfo/m5-users > > > > > _______________________________________________ > m5-users mailing list > [email protected] > http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
_______________________________________________ m5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
