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
On Fri, Jul 1, 2016 at 10:24 PM, Joel Hestness <jthestn...@gmail.com> wrote:
> 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 <
> azadeh.shirvan...@gmail.com> wrote:
>
>> 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
>> gem5-users@gem5.org
>> 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
> gem5-users@gem5.org
> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>
_______________________________________________
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
