Hi guys, I am using swig 1.3.40, so per Nate's note in the last changeset, I don't think that should be an issue.
@Steve: Thanks for the pointer to 'bisect'. Also, in debugging this problem, I ran into the same MC146818 checkpointing/drain bug from before. Previously, I had written a patch to fix the problem. However, I just talked to Brad about it, and he mentioned that you were thinking about backing out that changeset (7559). Based on what I see in the code, it's unclear whether my patch does the right thing and I think the previous code is certainly more correct. I backed out that changeset locally, and it fixed the MC146818 problem, so my recommendation would be to back out that changeset in the repo. If we're in agreement, should I submit that patch for review? So, back to the bug at hand: After a fair amount of testing, it looks like the checkpoint restore problem was introduced somewhere between changeset 7674 and 7678. (it would probably be another 30-40 minutes of testing for me to identify exactly) @Nate: I tried changing the module to 'internal', but it gave the same error. Is it just about getting the correct imports? Thanks, Joel On Wed, Sep 15, 2010 at 5:55 PM, nathan binkert <n...@binkert.org> wrote: > > if system.getMemoryMode() != objects.params.timing: > > AttributeError: 'module' object has no attribute 'timing' > > I'm pretty sure that this is my fault. Can you change it to > internal.params.timing and let me know if it works? > > Thanks, > > Nate > _______________________________________________ > m5-dev mailing list > m5-dev@m5sim.org > http://m5sim.org/mailman/listinfo/m5-dev > > -- > Joel Hestness > PhD Student, Computer Architecture > Dept. of Computer Science, University of Texas - Austin > http://www.cs.utexas.edu/~hestness > <http://m5sim.org/mailman/listinfo/m5-dev> >
_______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
