What I wrote was more of a hypothesis that might explain / help debug the
problem Joel is facing. I might be incorrect, though I faintly recall
facing some such problem my self.
I am more in favor of moving towards storing only architectural state in
the checkpoint so that we can restore from any cpu type. Any ideas as to
why we need fields like so_state, locked, status for atomic CPU?
--
Nilay
On Tue, 3 Apr 2012, Beckmann, Brad wrote:
Hmm...timing cpu restoring a checkpoint created by the atomic cpu used
to work? What changed with regards to interrupts broke it?
It would be great if we could maintain atomic -> timing checkpoint
capability. It is really useful to use the atomic cpu to fast-forward
to an interesting point in an application, take a checkpoint, then use
that checkpoint across multiple experiments using the timing cpu.
Brad
-----Original Message-----
From: [email protected] [mailto:[email protected]]
On Behalf Of Nilay Vaish
Sent: Tuesday, April 03, 2012 6:51 PM
To: gem5 Developer List
Subject: Re: [gem5-dev] x86 Checkpoint Restore Trouble
Joel, you might know that system being restored from a check point starts with
an atomic cpu by default. I think the problem you are facing is in initializing
a
timing CPU. IIRC, the interrupt controller is moved from atomic CPU to timing
CPU after X number of ticks. You might want to try restoring with a timing CPU
to begin with (use option --restore-cpu-type).
But I think you will run in to problem there as well if the checkpoint was
created using an atomic CPU as the check pointed state is a super set of the
architectural state and depends on the CPU type in use.
You might want to create check points using the timing CPU it self.
--
Nilay
On Tue, 3 Apr 2012, Joel Hestness wrote:
Hey guys,
I've tried searching around, but I'm having trouble finding any help
on this. Anyone have insights or pointers? Is checkpoint restore
supposed to be working?
---------------------------------------------------
joel@vein:~/research/gem5/gem5-latest$ ./build/X86/gem5.debug
./configs/example/fs.py --take-checkpoints=5000000000,1000000000000
gem5 Simulator System. http://gem5.org
gem5 is copyrighted software; use the --copyright option for details.
gem5 compiled Apr 3 2012 12:11:41
gem5 started Apr 3 2012 18:13:38
gem5 executing on vein
command line: ./build/X86/gem5.debug ./configs/example/fs.py
--take-checkpoints=5000000000,1000000000000
warning: add_child('terminal'): child 'terminal' already has parent
Global frequency set at 1000000000000 ticks per second
info: kernel located at:
/home/joel/research/gem5/full_system_files/binaries/x86_64-vmlinux-
2.6.28.4-smp
0: rtc: Real-time clock set to Sun Jan 1 00:00:00 2012 Listening
for com_1 connection on port 3458
warn: Reading current count from inactive timer.
0: system.remote_gdb.listener: listening for remote gdb #0 on port
7002
info: Entering event queue @ 0. Starting simulation...
warn: Don't know what interrupt to clear for console.
warn: instruction 'wbinvd' unimplemented Writing checkpoint
info: Entering event queue @ 5000000000. Starting simulation...
^Chack: be nice to actually delete the event here Exiting @ tick
5559293000 because user interrupt received
joel@vein:~/research/gem5/gem5-latest$ ./build/X86/gem5.debug
./configs/example/fs.py -r 1 --cpu-type=timing
gem5 Simulator System. http://gem5.org
gem5 is copyrighted software; use the --copyright option for details.
gem5 compiled Apr 3 2012 12:11:41
gem5 started Apr 3 2012 18:15:08
gem5 executing on vein
command line: ./build/X86/gem5.debug ./configs/example/fs.py -r 1
--cpu-type=timing
warning: add_child('terminal'): child 'terminal' already has parent
Global frequency set at 1000000000000 ticks per second
info: kernel located at:
/home/joel/research/gem5/full_system_files/binaries/x86_64-vmlinux-
2.6.28.4-smp
0: rtc: Real-time clock set to Sun Jan 1 00:00:00 2012 Listening
for com_1 connection on port 3458
*gem5.debug: build/X86/arch/x86/utility.cc:171: void
X86ISA::initCPU(ThreadContext*, int): Assertion `interrupts' failed.*
*Program aborted at cycle 0*
*Aborted*
---------------------------------------------------
For this test, I'm using changeset 8900 with Nilay's port fix patch here:
http://reviews.gem5.org/r/1102/
The same assertion failure happens for ruby_fs.py (and the script
that I've derived from ruby_fs.py).
Thanks!
Joel
--
Joel Hestness
PhD Student, Computer Architecture
Dept. of Computer Science, University of Texas - Austin
http://www.cs.utexas.edu/~hestness
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
