Quoting Steve Reinhardt <[email protected]>:

> On Fri, Apr 17, 2009 at 1:37 PM, nathan binkert <[email protected]> wrote:
>
>> >> I'm not an expert on this code, but I think it's preventing excessively
>> >> restarting the CPU if you do a switchover or resume from a checkpoint.
>> >
>> > Yea, that's exactly my assumption too, but I'd feel much better if
>> someone
>> > could explain in detail why it's necessary rather than just leaving it in
>> > out of the fear of the unknown.  For example, it seems wrong that init()
>> > would get called more than once on the same object.  Also if there are
>> cases
>> > where init() is called and the thread is *not* in its initial state, then
>> > when & where did the thread's state get changed?
>>
>> Can we even figure out who did what?  Can you trace hg annotate
>> through the renames and repository conversions and stuff to understand
>> it?  The thing is, I think the unfortunate answer is that the code
>> just grew completely organically without anyone really understanding
>> what's going on.
>>
>>  Nate
>
>
> Here's the changeset; it doesn't really provide any clues that I could find:
>
> http://repo.m5sim.org/m5/rev/db5f2da1271a
>
> I whacked that test entirely (so that the O3 init() calls initCPU()
> unconditionally in FS mode) and am running the long regressions and so far
> they've all passed.  However I don't think there's a switchover in the
> regressions so I'll have to test that separately.
>
> Steve
>

You should also be sure to test starting from a checkpoint which I  
believe is different from a switchover, although I'm not sure. I've  
done things in the past that seem fine and pass regressions but break  
that mechanism. Speaking of which, since I and potentially others  
don't know off hand how to use checkpointing (still!), we should  
probably make a regression to test those. I know we've agreed on that  
before, but this is another case where it would be good to have so I  
thought I'd bring it up.

Gabe
_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev

Reply via email to