Hi,
I've had a chance to reproduce this problem. Unfortunately, this looks
like something I ran into last year when we were getting x86 FS up and
running. We have been using the Ruby memory model instead of the classic
memory model, which requires a slightly different startup process when
restoring from a checkpoint; The classic model requires that the system be
instantiated and configured with the AtomicSimpleCPU before changing over to
timing mode/TimingSimpleCPU (I believe this is handled in the background by
gem5 for other architectures). It looks like the problem might be that the
order of component instantiation is different when restoring from a
checkpoint, and due to the order, the PIO port of the switch_cpu's interrupt
device is not connected.
This might be something that Steve or Nate could help with.
@Steve, Nate: Is there anything special that needs to be done to get the
order of component instantiation correct when restoring from a checkpoint?
Thanks,
Joel
On Fri, Jul 29, 2011 at 2:29 PM, Mahmood Naderan <[email protected]>wrote:
> mahmood@mpc:gem5$ hg tip
> changeset: 8477:4a6c166f61f7
> tag: tip
> user: Nilay Vaish<[email protected]>
> date: Tue Jul 26 12:20:22 2011 -0500
> summary: Ruby: Fix instantiations of DMA controller and sequencer
>
>
>
> --
> // Naderan *Mahmood;
> _______________________________________________
> gem5-users mailing list
> [email protected]
> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>
--
Joel Hestness
PhD Student, Computer Architecture
Dept. of Computer Science, University of Texas - Austin
http://www.cs.utexas.edu/~hestness
_______________________________________________
gem5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
