Discussion:
Restoring from the checkpoint created by hack_back_ckpt.rcS
(too old to reply)
Azadeh Shirvanian
2016-06-29 18:15:40 UTC
Permalink
Dear all,

I have got stuck somewhere regarding checkpoints. What I need to do is
running an image processing application, which takes an image as the input
and produces an image as the output, in full system mode and with X86.

I used *hack_back_ckpt.rcS* to create a checkpoint after booting Linux
using this command:

build/X86/gem5.opt configs/example/fs.py --cpu-type=atomic
--script=configs/boot/hack_back_ckpt.rcS

And to restore from that created checkpoint:

build/X86/gem5.opt configs/example/fs.py --cpu-clock="1GHz" --hit-latency=4
--caches --restore-with-cpu=DerivO3CPU -r 1 --script=configs/boot/cjpeg.rcS

I checked the simulation after 22 hours and everything looked like the day
before (The simulation was not finished yet). It seems that it has started
from the checkpoint, but it has not seen the script (cjpeg.rcS) at all...
My reason for it is that I mounted the disk image and there was no output
image created yet.

I stopped the simulation and started it again without the --script option,
the result was the same. I stopped that too and started the simulation
without --restore-with-cpu option, but nothing changed.

I think I have missed something in the way I restore from the checkpoint. I
do not know what that is. I should also mention that before creating the
checkpoint, everything was working (i.e., the simulation terminated with an
output image). The only problem was that I could not find the output image
on the disk image after the simulation was finished. So I modified
* FSConfig.py* a little before creating the checkpoint.

I have attached the simulation outputs of both creating the checkpoint and
restoring from it, as well as the terminal output of creating the
checkpoint. The terminal output file for restoring from the checkpoint was
empty.

I would appreciate any help or idea.

Best regards,
Azadeh
Jason Lowe-Power
2016-06-30 14:25:35 UTC
Permalink
Hi Azadeh,

I'm not certain what the problem is. However, you don't have to use the O3
CPU to "restore-with". That option is the CPU that is used during
checkpoint restore, not the CPU used once checkpoint restore is complete on
the main simulation. To choose which CPU to use for the main simulation use
--cpu-type.

How did you come to the conclusion that the system didn't load the
cjpeg.rcS file? Did you look at the terminal output of the system while it
was running the main simulation (after restoring from the checkpoint)?
Another thing you can do is restore with and without a script and connect
via m5term (see gem5/util/term) and double check the guest system is in the
state you expect.

Cheers,
Jason

On Wed, Jun 29, 2016 at 1:16 PM Azadeh Shirvanian <
Post by Azadeh Shirvanian
Dear all,
I have got stuck somewhere regarding checkpoints. What I need to do is
running an image processing application, which takes an image as the input
and produces an image as the output, in full system mode and with X86.
I used *hack_back_ckpt.rcS* to create a checkpoint after booting Linux
build/X86/gem5.opt configs/example/fs.py --cpu-type=atomic
--script=configs/boot/hack_back_ckpt.rcS
build/X86/gem5.opt configs/example/fs.py --cpu-clock="1GHz"
--hit-latency=4 --caches --restore-with-cpu=DerivO3CPU -r 1
--script=configs/boot/cjpeg.rcS
I checked the simulation after 22 hours and everything looked like the day
before (The simulation was not finished yet). It seems that it has started
from the checkpoint, but it has not seen the script (cjpeg.rcS) at all...
My reason for it is that I mounted the disk image and there was no output
image created yet.
I stopped the simulation and started it again without the --script option,
the result was the same. I stopped that too and started the simulation
without --restore-with-cpu option, but nothing changed.
I think I have missed something in the way I restore from the checkpoint.
I do not know what that is. I should also mention that before creating the
checkpoint, everything was working (i.e., the simulation terminated with an
output image). The only problem was that I could not find the output image
on the disk image after the simulation was finished. So I modified
* FSConfig.py* a little before creating the checkpoint.
I have attached the simulation outputs of both creating the checkpoint and
restoring from it, as well as the terminal output of creating the
checkpoint. The terminal output file for restoring from the checkpoint was
empty.
I would appreciate any help or idea.
Best regards,
Azadeh
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Azadeh Shirvanian
2016-07-01 19:09:43 UTC
Permalink
Hi Jason,

Thank you for the important point about the options --restore-with-cpu and
--cpu-type.

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 of them...

Regards,
Azadeh
Ayaz Akram
2016-07-01 20:20:51 UTC
Permalink
Azadeh: Regarding output JPEG file on disk image, due to COW functionality
Simulation does not change the contents of disk image. So, once you are
done with simulation you cannot see output files on disk image unless you
turn off the COW layer.


On Fri, Jul 1, 2016 at 3:09 PM, Azadeh Shirvanian <
Post by Azadeh Shirvanian
Hi Jason,
Thank you for the important point about the options --restore-with-cpu and
--cpu-type.
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 of
them...
Regards,
Azadeh
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Joel Hestness
2016-07-01 20:24:05 UTC
Permalink
Hi Azadeh,
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).

Here are a couple more questions to help debug:

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.

Joel


On Fri, Jul 1, 2016 at 2:09 PM, Azadeh Shirvanian <
Post by Azadeh Shirvanian
Hi Jason,
Thank you for the important point about the options --restore-with-cpu and
--cpu-type.
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 of
them...
Regards,
Azadeh
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
--
Joel Hestness
PhD Candidate, Computer Architecture
Dept. of Computer Science, University of Wisconsin - Madison
http://pages.cs.wisc.edu/~hestness/
Azadeh Shirvanian
2016-07-02 14:23:45 UTC
Permalink
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:

#!/bin/sh

cd /jpeg/jpeg-6a
./cjpeg -outfile ../gm.jpg ../input.ppm
/sbin/m5 exit
/sbin/m5 exit

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:

class RawIdeDisk(IdeDisk):
image = RawDiskImage(read_only=False)
def childImage(self, ci):
self.image.image_file=ci

and commented this part:

#class CowIdeDisk(IdeDisk):
# image = CowDiskImage(child=RawDiskImage(read_only=True),
# read_only=False)

# 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.

Best regards,
Azadeh
Post by Jason Lowe-Power
Hi Azadeh,
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.
Joel
On Fri, Jul 1, 2016 at 2:09 PM, Azadeh Shirvanian <
Post by Azadeh Shirvanian
Hi Jason,
Thank you for the important point about the options --restore-with-cpu
and --cpu-type.
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
of them...
Regards,
Azadeh
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
--
Joel Hestness
PhD Candidate, Computer Architecture
Dept. of Computer Science, University of Wisconsin - Madison
http://pages.cs.wisc.edu/~hestness/
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Joel Hestness
2016-07-02 17:10:13 UTC
Permalink
Hi Azadeh,
I just realized what might be going on. It looks like you attached a
terminal during your simulation to collect the checkpoint (bolded in your
checkpoint sim output snippet below):

0: system.remote_gdb.listener: listening for remote gdb #0 on port 7000
**** REAL SIMULATION ****
info: Entering event queue @ 0. Starting simulation...
warn: Don't know what interrupt to clear for console.
warn: x86 cpuid: unknown family 0x8086*124693755000:
system.pc.com_1.terminal: attach terminal 0*
warn: Tried to clear PCI interrupt 14
warn: Unknown mouse command 0xe1.
warn: instruction 'wbinvd' unimplemented
Writing checkpoint


When you do this, the simulated system will try to give you terminal access
as soon as possible, and this might be sending the hack_back_ckpt.rcS
script off the rails. I'd recommend trying to recollect your checkpoint
without attaching a terminal to let the hack_back_ckpt.rcS script complete
without any potential interruption. If you want to track the process of the
simulated system as it boots Linux, you can tail the
system.pc.com_1.terminal file in your output directory rather than
attaching a terminal.


Hope this helps,
Joel




On Sat, Jul 2, 2016 at 9:23 AM, Azadeh Shirvanian <
Post by Azadeh Shirvanian
Dear Joel and Ayaz,
Thanks for your replies. I think there are two issues now. One is about
restoring from the checkpoint.
#!/bin/sh
cd /jpeg/jpeg-6a
./cjpeg -outfile ../gm.jpg ../input.ppm
/sbin/m5 exit
/sbin/m5 exit
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*
==== 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
image = RawDiskImage(read_only=False)
self.image.image_file=ci
# image = CowDiskImage(child=RawDiskImage(read_only=True),
# read_only=False)
# self.image.child.image_file = ci
# disk0 = CowIdeDisk(driveID='master')
# disk2 = CowIdeDisk(driveID='master')
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.
Best regards,
Azadeh
Post by Jason Lowe-Power
Hi Azadeh,
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.
Joel
On Fri, Jul 1, 2016 at 2:09 PM, Azadeh Shirvanian <
Post by Azadeh Shirvanian
Hi Jason,
Thank you for the important point about the options --restore-with-cpu
and --cpu-type.
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
of them...
Regards,
Azadeh
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
--
Joel Hestness
PhD Candidate, Computer Architecture
Dept. of Computer Science, University of Wisconsin - Madison
http://pages.cs.wisc.edu/~hestness/
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
--
Joel Hestness
PhD Candidate, Computer Architecture
Dept. of Computer Science, University of Wisconsin - Madison
http://pages.cs.wisc.edu/~hestness/
Azadeh Shirvanian
2016-07-02 18:40:19 UTC
Permalink
Hi Joel,

I see... Thank you! I will try it and will write about the result.

Best regards,
Azadeh
Post by Jason Lowe-Power
Hi Azadeh,
I just realized what might be going on. It looks like you attached a
terminal during your simulation to collect the checkpoint (bolded in your
0: system.remote_gdb.listener: listening for remote gdb #0 on port 7000
**** REAL SIMULATION ****
warn: Don't know what interrupt to clear for console.
warn: x86 cpuid: unknown family 0x8086*124693755000: system.pc.com_1.terminal: attach terminal 0*
warn: Tried to clear PCI interrupt 14
warn: Unknown mouse command 0xe1.
warn: instruction 'wbinvd' unimplemented
Writing checkpoint
When you do this, the simulated system will try to give you terminal
access as soon as possible, and this might be sending the
hack_back_ckpt.rcS script off the rails. I'd recommend trying to recollect
your checkpoint without attaching a terminal to let the hack_back_ckpt.rcS
script complete without any potential interruption. If you want to track
the process of the simulated system as it boots Linux, you can tail the
system.pc.com_1.terminal file in your output directory rather than
attaching a terminal.
Hope this helps,
Joel
On Sat, Jul 2, 2016 at 9:23 AM, Azadeh Shirvanian <
Post by Azadeh Shirvanian
Dear Joel and Ayaz,
Thanks for your replies. I think there are two issues now. One is about
restoring from the checkpoint.
#!/bin/sh
cd /jpeg/jpeg-6a
./cjpeg -outfile ../gm.jpg ../input.ppm
/sbin/m5 exit
/sbin/m5 exit
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*
==== 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
image = RawDiskImage(read_only=False)
self.image.image_file=ci
# image = CowDiskImage(child=RawDiskImage(read_only=True),
# read_only=False)
# self.image.child.image_file = ci
# disk0 = CowIdeDisk(driveID='master')
# disk2 = CowIdeDisk(driveID='master')
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.
Best regards,
Azadeh
Post by Jason Lowe-Power
Hi Azadeh,
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.
Joel
On Fri, Jul 1, 2016 at 2:09 PM, Azadeh Shirvanian <
Post by Azadeh Shirvanian
Hi Jason,
Thank you for the important point about the options --restore-with-cpu
and --cpu-type.
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
of them...
Regards,
Azadeh
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
--
Joel Hestness
PhD Candidate, Computer Architecture
Dept. of Computer Science, University of Wisconsin - Madison
http://pages.cs.wisc.edu/~hestness/
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
--
Joel Hestness
PhD Candidate, Computer Architecture
Dept. of Computer Science, University of Wisconsin - Madison
http://pages.cs.wisc.edu/~hestness/
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Azadeh Shirvanian
2016-07-05 18:31:46 UTC
Permalink
Hi Joel,

The problem of restoring from the checkpoint is solved by recollecting the
checkpoint, this time without attaching a terminal. Thanks for your help.

Best regards,
Azadeh



On Sat, Jul 2, 2016 at 8:40 PM, Azadeh Shirvanian <
Post by Azadeh Shirvanian
Hi Joel,
I see... Thank you! I will try it and will write about the result.
Best regards,
Azadeh
Post by Jason Lowe-Power
Hi Azadeh,
I just realized what might be going on. It looks like you attached a
terminal during your simulation to collect the checkpoint (bolded in your
0: system.remote_gdb.listener: listening for remote gdb #0 on port 7000
**** REAL SIMULATION ****
warn: Don't know what interrupt to clear for console.
warn: x86 cpuid: unknown family 0x8086*124693755000: system.pc.com_1.terminal: attach terminal 0*
warn: Tried to clear PCI interrupt 14
warn: Unknown mouse command 0xe1.
warn: instruction 'wbinvd' unimplemented
Writing checkpoint
When you do this, the simulated system will try to give you terminal
access as soon as possible, and this might be sending the
hack_back_ckpt.rcS script off the rails. I'd recommend trying to recollect
your checkpoint without attaching a terminal to let the hack_back_ckpt.rcS
script complete without any potential interruption. If you want to track
the process of the simulated system as it boots Linux, you can tail the
system.pc.com_1.terminal file in your output directory rather than
attaching a terminal.
Hope this helps,
Joel
On Sat, Jul 2, 2016 at 9:23 AM, Azadeh Shirvanian <
Post by Azadeh Shirvanian
Dear Joel and Ayaz,
Thanks for your replies. I think there are two issues now. One is about
restoring from the checkpoint.
#!/bin/sh
cd /jpeg/jpeg-6a
./cjpeg -outfile ../gm.jpg ../input.ppm
/sbin/m5 exit
/sbin/m5 exit
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
==== 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
image = RawDiskImage(read_only=False)
self.image.image_file=ci
# image = CowDiskImage(child=RawDiskImage(read_only=True),
# read_only=False)
# self.image.child.image_file = ci
# disk0 = CowIdeDisk(driveID='master')
# disk2 = CowIdeDisk(driveID='master')
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.
Best regards,
Azadeh
Post by Jason Lowe-Power
Hi Azadeh,
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.
Joel
On Fri, Jul 1, 2016 at 2:09 PM, Azadeh Shirvanian <
Post by Azadeh Shirvanian
Hi Jason,
Thank you for the important point about the options --restore-with-cpu
and --cpu-type.
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 of them...
Regards,
Azadeh
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
--
Joel Hestness
PhD Candidate, Computer Architecture
Dept. of Computer Science, University of Wisconsin - Madison
http://pages.cs.wisc.edu/~hestness/
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
--
Joel Hestness
PhD Candidate, Computer Architecture
Dept. of Computer Science, University of Wisconsin - Madison
http://pages.cs.wisc.edu/~hestness/
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Continue reading on narkive:
Loading...