Hi Joel, I see... Thank you! I will try it and will write about the result.
Best regards, Azadeh On Sat, Jul 2, 2016 at 7:10 PM, Joel Hestness <jthestn...@gmail.com> wrote: > 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 < > azadeh.shirvan...@gmail.com> wrote: > >> 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 >> > > > > -- > 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
