Dear Joel and Ayaz,
Thanks for your replies. I think there are two issues now. One is about
restoring from the checkpoint.
Regarding your questions, Joel, *cjpeg.rcS* contains the following:
./cjpeg -outfile ../gm.jpg ../input.ppm
It only executes the binary called *cjpeg*, which takes a PPM image as the
input and converts this image to a JPEG.
And yes, I was able to attach a terminal to a restored simulation without
--script specified, but I couldn't execute the commands in *cjpeg.rcS*
because in the attached terminal I only see:
==== m5 slave terminal: Terminal 0 ====
and nothing after that. In other words, I never get the chance to type
anything there. The only thing I can do is to press Ctrl+C and stop it! :)
In fact, this was and is the result of whatever I tried about restoring
from the checkpoint.
The other issue is about the existence of the JPEG file on the disk image
after the simulation. Regarding this, I should say that before I created
the checkpoint, I modified *FSConfig.py *and removed the COW layer. The
following are the changes that I made:
I added this part at the beginning:
image = RawDiskImage(read_only=False)
def childImage(self, ci):
and commented this part:
# image = CowDiskImage(child=RawDiskImage(read_only=True),
# def childImage(self, ci):
# self.image.child.image_file = ci
Then inside def makeX86System, I commented these two lines:
# disk0 = CowIdeDisk(driveID='master')
# disk2 = CowIdeDisk(driveID='master')
and added these instead:
disk0 = RawIdeDisk(driveID='master')
disk2 = RawIdeDisk(driveID='master')
I was hoping to be able to find the output file on the disk image (after
the simulation was complete) and then copy it to somewhere in the host
system... I'm not sure now if it is possible at all.
Post by Jason Lowe-Power
I'm still not sure what could be going wrong. Note that gem5 does not
write to disk images, so you won't see simulation output (unless you attach
a terminal to the simulated system after running the benchmark in FS mode
and browse the image from the simulator).
1) Can you send over your cjpeg.rcS script, so we can see what it is
supposed to do?
2) Are you able to attach a terminal to a restored simulation without
--script specified, and then execute the commands in cjpeg.rcS? If so, then
I would guess there is something wrong with the hack_back_ckpt.rcS process
to load the new script in the simulated system. If you can't execute the
commands in cjpeg.rcS at the terminal, then you might have to adjust the
script as appropriate. If you can't attach a terminal or execute commands,
then I would guess that something is wrong with the checkpoint.
On Fri, Jul 1, 2016 at 2:09 PM, Azadeh Shirvanian <
Post by Azadeh Shirvanian
Thank you for the important point about the options --restore-with-cpu
And yes, I looked at the terminal output (using m5term) for the main
simulation after restoring from the checkpoint and I don't see anything
there. As I wrote at the end of my last email, the file
*system.pc.com_1.terminal* is empty here.
Since I had run the application cjpeg in SE mode before I started with FS
mode, I know that once the application starts to run, an output file, which
is a JPEG file, is created. After I observed that the main simulation is
not finished after 22 hours, I opened a new terminal and mounted the disk
image to check whether the output JPEG file is created or not, and it
wasn't there. That's why I concluded that the script *cjpeg.rcS* didn't
run at all.
I also tested restoring without a script, or by creating a checkpoint
(after booting) without the script *hack_back_ckpt.rcS *(I used the
option --checkpoint-at-end), and the result was still the same for all
gem5-users mailing list
PhD Candidate, Computer Architecture
Dept. of Computer Science, University of Wisconsin - Madison
gem5-users mailing list