THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added:
FS#337 - Checkpoint Tester Identifies Mismatches (Bugs) for X86_FS User who did this: - Gabe Black (gblack) ---------- The differences in state look like basically one more (or less) instruction/microop executed between the two instances. My very off the cuff hunch is that the macroop isn't being checkpointed, so when the CPU starts up again it has to fetch the instruction, decode it to a macroop, and then start executing the microops. When it's not from a checkpoint, the macroop is already there and ready to go. If that is what's happening, no trivial fix springs to mind, though here are some non-trivial possibilities. One would be to force the current macroop to finish executing and consider that part of draining (right term?), although there's no guaranteed bound to how long a macroop can take. They would practically tend to be short, but "tend to" isn't something to design around. Alternatively, when dropping a checkpoint we could just forcefully lose track of the macroop so it has to be fetched again in both cases. A third option would be to serialize the macroop itself by serializing it's ExtMachInst, although I suspect there would be complications and it isn't clear it would be worthwhile unless checkpointing was frequent enough to cause statistically meaningful differences in behavior without that sort of thing. ---------- More information can be found at the following URL: http://www.m5sim.org/flyspray/task/337#comment159 You are receiving this message because you have requested it from the Flyspray bugtracking system. You can be removed from future notifications by visiting the URL shown above. _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
