On Feb 18, 2009, at 9:01 PM, nathan binkert wrote: >> Hmm...it is derived from PhysicalMemory, so from that viewpoint all >> it >> needs is to be rebuilt using the same parameters and have the >> underlying PhysicalMemory data restored correctly. If PhysicalMemory >> currently works with checkpointing, I am unclear what in my DRAMsim >> code prevents it from working, since I do not override either >> serialize or unserialize. Any ideas on what to look for? > > Well, the error isn't with serialize/unserialize actually, it's with > the drain code that forces the memory system to drain all in flight > requests. We do the drain before we take a checkpoint to make sure we > don't lose any data. It's possible that it's not a bug with DRAMsim, but rather some other issue with M5. What other components are you simulating? Do you have a NIC in the simulation? I know that over the last few months I've fixed one or two checkpointing bugs with the Intel NIC model. A good start to understanding the problem is printing out the value of getCount() before that assert occurs. A value less than 0 means that some object called process() on it's drainEvent more than it should have. I don't think a positive value is possible.
Ali _______________________________________________ m5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
