[gem5-users] Latency_input ARM FS
Hi, I'm running bbench in gem5 with this configuration: Dcache latency: 2.5 ns L2 latency: 15.8 ns Mem Latency: 100 ns and I've the following statistics: *system.l2.overall_avg_mshr_miss_latency::cpu.data 116713.648032* *system.l2.overall_avg_miss_latency::cpu.data 136045.358298* * * It seems like hit latency is used in access and response. So * avg_miss_latency*= 15.8**2*+2.5+2(buses latency) +100=136.1? Is it right? Thanks in advance Regards, Ali Chaker ___ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
[gem5-users] Running Android on gem5
Hello, Please forgive me if I am TOTALLY new to the concept of architecture simulation. At this stage I am trying to get the picture by building and playing with the pre-compiled images. What i want: I saw in the latest presentation in the tutorial part og gem5 wiki, the developers have set up the system to run angry birds on Android over ARM processor. That is what i want to do now. what I have done so far: from "BBench-gem5" part of the wiki, I followed "Running BBench on Android with gem5" section and I got the following on my ubuntu-32 bit os terminal. Am I in the right track? what should i do next? thank you: vahid@vahid-ThinkPad-T420:~/gem5$ build/ARM/m5.debug configs/example/fs.py -b bbench-gb --kernel=vmlinux.smp.mouse.arm gem5 Simulator System. http://gem5.org gem5 is copyrighted software; use the --copyright option for details. gem5 compiled Aug 23 2012 10:03:32 gem5 started Aug 24 2012 15:37:05 gem5 executing on vahid-ThinkPad-T420 command line: build/ARM/m5.debug configs/example/fs.py -b bbench-gb --kernel=vmlinux.smp.mouse.arm Global frequency set at 1 ticks per second info: kernel located at: /home/vahid/gem5/system/binaries/vmlinux.smp.mouse.arm Listening for system connection on port 5900 Listening for system connection on port 3456 0: system.remote_gdb.listener: listening for remote gdb #0 on port 7000 info: Using bootloader at address 0x8000 REAL SIMULATION info: Entering event queue @ 0. Starting simulation... warn: The clidr register always reports 0 caches. warn: clidr LoUIS field of 0b001 to match current ARM implementations. warn: The csselr register isn't implemented. warn: instruction 'mcr bpiallis' unimplemented warn: instruction 'mcr icialluis' unimplemented warn: The ccsidr register isn't implemented and always reads as 0. warn: instruction 'mcr dccimvac' unimplemented warn: instruction 'mcr dccmvau' unimplemented warn: instruction 'mcr icimvau' unimplemented warn: instruction 'mcr bpiallis' unimplemented warn: LCD dual screen mode not supported warn: instruction 'mcr bpiallis' unimplemented warn: instruction 'mcr icialluis' unimplemented warn: instruction 'mcr bpiallis' unimplemented ___ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Re: [gem5-users] Running Android on gem5
You can install APKs directly to a disk image by placing the .apk file in the /system/app directory. This has worked for me in the past. However, installing them doesn't guarantee that gem5 is able to run them. Angry Birds is a proprietary piece of software and the apk is only available for Android through the Android Marketplace as far as I know. Hypothetically, you could download this apk from the marketplace and then use adb to extract it from the phone/tablet/other Android device. But, I would never advocate such things, as they violate Google's user agreement... -Tony On Fri, Aug 24, 2012 at 7:21 AM, Wahid wrote: > Hello, > Please forgive me if I am TOTALLY new to the concept of architecture > simulation. At this stage I am trying to get the picture by building and > playing with the pre-compiled images. > > What i want: > I saw in the latest presentation in the tutorial part og gem5 wiki, the > developers have set up the system to run angry birds on Android over ARM > processor. That is what i want to do now. > > what I have done so far: > from "BBench-gem5" part of the wiki, I followed "Running BBench on Android > with gem5" section and I got the following on my ubuntu-32 bit os terminal. > Am I in the right track? what should i do next? thank you: > > vahid@vahid-ThinkPad-T420:~/gem5$ build/ARM/m5.debug > configs/example/fs.py -b bbench-gb --kernel=vmlinux.smp.mouse.arm > gem5 Simulator System. http://gem5.org > gem5 is copyrighted software; use the --copyright option for details. > > gem5 compiled Aug 23 2012 10:03:32 > gem5 started Aug 24 2012 15:37:05 > gem5 executing on vahid-ThinkPad-T420 > command line: build/ARM/m5.debug configs/example/fs.py -b bbench-gb > --kernel=vmlinux.smp.mouse.arm > Global frequency set at 1 ticks per second > info: kernel located at: > /home/vahid/gem5/system/binaries/vmlinux.smp.mouse.arm > Listening for system connection on port 5900 > Listening for system connection on port 3456 > 0: system.remote_gdb.listener: listening for remote gdb #0 on port 7000 > info: Using bootloader at address 0x8000 > REAL SIMULATION > info: Entering event queue @ 0. Starting simulation... > warn: The clidr register always reports 0 caches. > warn: clidr LoUIS field of 0b001 to match current ARM implementations. > warn: The csselr register isn't implemented. > warn: instruction 'mcr bpiallis' unimplemented > warn: instruction 'mcr icialluis' unimplemented > warn: The ccsidr register isn't implemented and always reads as 0. > warn: instruction 'mcr dccimvac' unimplemented > warn: instruction 'mcr dccmvau' unimplemented > warn: instruction 'mcr icimvau' unimplemented > warn: instruction 'mcr bpiallis' unimplemented > warn: LCD dual screen mode not supported > warn: instruction 'mcr bpiallis' unimplemented > warn: instruction 'mcr icialluis' unimplemented > warn: instruction 'mcr bpiallis' unimplemented > > > > > > ___ > 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
Re: [gem5-users] Question about instruction-based exit events.
Tony,
check the nop count. That might be the difference that you are seeing.
-Korey
On Thu, Aug 23, 2012 at 1:24 PM, Anthony Gutierrez wrote:
> Hello,
>
> It seems that the number of committed instructions don't always match up
> with an instruction-based exit event, e.g., when using -I. The CPU's number
> of committedInsts can sometime be a few more or less than this value. I
> think I understand why the number can be more, if an exit event is scheduled
> when commit commits its 1,000th instruction, other events scheduled for the
> same tick can cause more instructions to be committed. Is that correct? But,
> why can the number of committed instructions ever be less than the number
> that triggers an exit event? I added this to the O3 cpu and dumped and reset
> stats after every exit:
>
> //inside of instDone()
> if (!(thread[tid]->numInst % 1000))
> exitSimLoop("1000 insts reached", 0);
>
> The number of committedInsts dumped after each exit varies but it usually
> within a few % of 1,000. However, it is rarely ever 1,000.
>
> Thanks,
> Tony
>
> ___
> gem5-users mailing list
> gem5-users@gem5.org
> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
--
- Korey
___
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Re: [gem5-users] Question about instruction-based exit events.
This is the part of the code where the committedInsts get's incremented, so
it should match up with that and has nothing to do with the ops.
-Tony
On Fri, Aug 24, 2012 at 10:16 AM, Korey Sewell wrote:
> Tony,
> check the nop count. That might be the difference that you are seeing.
>
> -Korey
>
> On Thu, Aug 23, 2012 at 1:24 PM, Anthony Gutierrez
> wrote:
> > Hello,
> >
> > It seems that the number of committed instructions don't always match up
> > with an instruction-based exit event, e.g., when using -I. The CPU's
> number
> > of committedInsts can sometime be a few more or less than this value. I
> > think I understand why the number can be more, if an exit event is
> scheduled
> > when commit commits its 1,000th instruction, other events scheduled for
> the
> > same tick can cause more instructions to be committed. Is that correct?
> But,
> > why can the number of committed instructions ever be less than the number
> > that triggers an exit event? I added this to the O3 cpu and dumped and
> reset
> > stats after every exit:
> >
> > //inside of instDone()
> > if (!(thread[tid]->numInst % 1000))
> > exitSimLoop("1000 insts reached", 0);
> >
> > The number of committedInsts dumped after each exit varies but it usually
> > within a few % of 1,000. However, it is rarely ever 1,000.
> >
> > Thanks,
> > Tony
> >
> > ___
> > gem5-users mailing list
> > gem5-users@gem5.org
> > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>
>
>
> --
> - Korey
> ___
> 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
Re: [gem5-users] Question about instruction-based exit events.
I'm saying that the nops may not get counted in committedInsts. Other
users have reported issues when comparing the committed instruction
count between CPU models and typically this is the problem.
If you look in commit_impl.hh, around line 109, you'll see that
instDone() will not get called if the instruction is a nop or
prefetch.
However, a couple of lines earlier committedOps and committedInsts can
be incremented in cases where instDone() isn't called.
This may be the discrepancy that you are seeing.
-Korey
On Fri, Aug 24, 2012 at 8:04 AM, Anthony Gutierrez wrote:
> This is the part of the code where the committedInsts get's incremented, so
> it should match up with that and has nothing to do with the ops.
>
> -Tony
>
>
> On Fri, Aug 24, 2012 at 10:16 AM, Korey Sewell wrote:
>>
>> Tony,
>> check the nop count. That might be the difference that you are seeing.
>>
>> -Korey
>>
>> On Thu, Aug 23, 2012 at 1:24 PM, Anthony Gutierrez
>> wrote:
>> > Hello,
>> >
>> > It seems that the number of committed instructions don't always match up
>> > with an instruction-based exit event, e.g., when using -I. The CPU's
>> > number
>> > of committedInsts can sometime be a few more or less than this value. I
>> > think I understand why the number can be more, if an exit event is
>> > scheduled
>> > when commit commits its 1,000th instruction, other events scheduled for
>> > the
>> > same tick can cause more instructions to be committed. Is that correct?
>> > But,
>> > why can the number of committed instructions ever be less than the
>> > number
>> > that triggers an exit event? I added this to the O3 cpu and dumped and
>> > reset
>> > stats after every exit:
>> >
>> > //inside of instDone()
>> > if (!(thread[tid]->numInst % 1000))
>> > exitSimLoop("1000 insts reached", 0);
>> >
>> > The number of committedInsts dumped after each exit varies but it
>> > usually
>> > within a few % of 1,000. However, it is rarely ever 1,000.
>> >
>> > Thanks,
>> > Tony
>> >
>> > ___
>> > gem5-users mailing list
>> > gem5-users@gem5.org
>> > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>
>>
>>
>> --
>> - Korey
>> ___
>> 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
--
- Korey
___
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Re: [gem5-users] Question about instruction-based exit events.
typo:
*around line 1009
On Fri, Aug 24, 2012 at 9:20 AM, Korey Sewell wrote:
> I'm saying that the nops may not get counted in committedInsts. Other
> users have reported issues when comparing the committed instruction
> count between CPU models and typically this is the problem.
>
> If you look in commit_impl.hh, around line 109, you'll see that
> instDone() will not get called if the instruction is a nop or
> prefetch.
>
> However, a couple of lines earlier committedOps and committedInsts can
> be incremented in cases where instDone() isn't called.
>
> This may be the discrepancy that you are seeing.
>
> -Korey
>
> On Fri, Aug 24, 2012 at 8:04 AM, Anthony Gutierrez wrote:
>> This is the part of the code where the committedInsts get's incremented, so
>> it should match up with that and has nothing to do with the ops.
>>
>> -Tony
>>
>>
>> On Fri, Aug 24, 2012 at 10:16 AM, Korey Sewell wrote:
>>>
>>> Tony,
>>> check the nop count. That might be the difference that you are seeing.
>>>
>>> -Korey
>>>
>>> On Thu, Aug 23, 2012 at 1:24 PM, Anthony Gutierrez
>>> wrote:
>>> > Hello,
>>> >
>>> > It seems that the number of committed instructions don't always match up
>>> > with an instruction-based exit event, e.g., when using -I. The CPU's
>>> > number
>>> > of committedInsts can sometime be a few more or less than this value. I
>>> > think I understand why the number can be more, if an exit event is
>>> > scheduled
>>> > when commit commits its 1,000th instruction, other events scheduled for
>>> > the
>>> > same tick can cause more instructions to be committed. Is that correct?
>>> > But,
>>> > why can the number of committed instructions ever be less than the
>>> > number
>>> > that triggers an exit event? I added this to the O3 cpu and dumped and
>>> > reset
>>> > stats after every exit:
>>> >
>>> > //inside of instDone()
>>> > if (!(thread[tid]->numInst % 1000))
>>> > exitSimLoop("1000 insts reached", 0);
>>> >
>>> > The number of committedInsts dumped after each exit varies but it
>>> > usually
>>> > within a few % of 1,000. However, it is rarely ever 1,000.
>>> >
>>> > Thanks,
>>> > Tony
>>> >
>>> > ___
>>> > gem5-users mailing list
>>> > gem5-users@gem5.org
>>> > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>>
>>>
>>>
>>> --
>>> - Korey
>>> ___
>>> 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
>
>
>
> --
> - Korey
--
- Korey
___
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Re: [gem5-users] Question about instruction-based exit events.
I know nops don't get counted and I'm taking that into account. The -I
option exits based on thread[tid]->numInst, this is incremented in the same
way as committedInst, i.e., neither count nops. I can't see why if I exit
on thread[tid]->numInst == 1000, the stats file shows something different.
The committedInsts (it's actually commitCommittedInsts) inside of
commit_impl.hh are the insts for the commit stage and they are counted
differently. I'm only looking at the CPUs committedInsts stat, which is
only ever incremented when thread[tid]->numInst is also incremented as far
as I can tell.
For example, a simple run of stock gem5 gives:
./build/ALPHA/m5.opt configs/example/fs.py --cpu-type=detailed --caches
--l2cache -I 20043
sim_insts = 200045
system.cpu.commit.commitedInsts = 200169 (These DO count nops as mentioned
above)
system.cpu.committedInsts = 200045 (These DO NOT count nops)
I can't find where the discrepancy is coming from.
-Tony
On Fri, Aug 24, 2012 at 12:20 PM, Korey Sewell wrote:
> I'm saying that the nops may not get counted in committedInsts. Other
> users have reported issues when comparing the committed instruction
> count between CPU models and typically this is the problem.
>
> If you look in commit_impl.hh, around line 109, you'll see that
> instDone() will not get called if the instruction is a nop or
> prefetch.
>
> However, a couple of lines earlier committedOps and committedInsts can
> be incremented in cases where instDone() isn't called.
>
> This may be the discrepancy that you are seeing.
>
> -Korey
>
> On Fri, Aug 24, 2012 at 8:04 AM, Anthony Gutierrez
> wrote:
> > This is the part of the code where the committedInsts get's incremented,
> so
> > it should match up with that and has nothing to do with the ops.
> >
> > -Tony
> >
> >
> > On Fri, Aug 24, 2012 at 10:16 AM, Korey Sewell
> wrote:
> >>
> >> Tony,
> >> check the nop count. That might be the difference that you are seeing.
> >>
> >> -Korey
> >>
> >> On Thu, Aug 23, 2012 at 1:24 PM, Anthony Gutierrez
> >> wrote:
> >> > Hello,
> >> >
> >> > It seems that the number of committed instructions don't always match
> up
> >> > with an instruction-based exit event, e.g., when using -I. The CPU's
> >> > number
> >> > of committedInsts can sometime be a few more or less than this value.
> I
> >> > think I understand why the number can be more, if an exit event is
> >> > scheduled
> >> > when commit commits its 1,000th instruction, other events scheduled
> for
> >> > the
> >> > same tick can cause more instructions to be committed. Is that
> correct?
> >> > But,
> >> > why can the number of committed instructions ever be less than the
> >> > number
> >> > that triggers an exit event? I added this to the O3 cpu and dumped and
> >> > reset
> >> > stats after every exit:
> >> >
> >> > //inside of instDone()
> >> > if (!(thread[tid]->numInst % 1000))
> >> > exitSimLoop("1000 insts reached", 0);
> >> >
> >> > The number of committedInsts dumped after each exit varies but it
> >> > usually
> >> > within a few % of 1,000. However, it is rarely ever 1,000.
> >> >
> >> > Thanks,
> >> > Tony
> >> >
> >> > ___
> >> > gem5-users mailing list
> >> > gem5-users@gem5.org
> >> > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
> >>
> >>
> >>
> >> --
> >> - Korey
> >> ___
> >> 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
>
>
>
> --
> - Korey
> ___
> 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
Re: [gem5-users] Question about instruction-based exit events.
Also, counting of faulting instructions (do we double-count) can also
get funny so you may want to double check that.
What you can do is place an assert that compares the two differing
numbers so that you find the exact spot where the inst counts start to
diverge.
On Fri, Aug 24, 2012 at 9:47 AM, Anthony Gutierrez wrote:
> I know nops don't get counted and I'm taking that into account. The -I
> option exits based on thread[tid]->numInst, this is incremented in the same
> way as committedInst, i.e., neither count nops. I can't see why if I exit on
> thread[tid]->numInst == 1000, the stats file shows something different.
>
> The committedInsts (it's actually commitCommittedInsts) inside of
> commit_impl.hh are the insts for the commit stage and they are counted
> differently. I'm only looking at the CPUs committedInsts stat, which is only
> ever incremented when thread[tid]->numInst is also incremented as far as I
> can tell.
>
> For example, a simple run of stock gem5 gives:
>
> ./build/ALPHA/m5.opt configs/example/fs.py --cpu-type=detailed --caches
> --l2cache -I 20043
>
> sim_insts = 200045
> system.cpu.commit.commitedInsts = 200169 (These DO count nops as mentioned
> above)
> system.cpu.committedInsts = 200045 (These DO NOT count nops)
>
> I can't find where the discrepancy is coming from.
>
> -Tony
>
>
> On Fri, Aug 24, 2012 at 12:20 PM, Korey Sewell wrote:
>>
>> I'm saying that the nops may not get counted in committedInsts. Other
>> users have reported issues when comparing the committed instruction
>> count between CPU models and typically this is the problem.
>>
>> If you look in commit_impl.hh, around line 109, you'll see that
>> instDone() will not get called if the instruction is a nop or
>> prefetch.
>>
>> However, a couple of lines earlier committedOps and committedInsts can
>> be incremented in cases where instDone() isn't called.
>>
>> This may be the discrepancy that you are seeing.
>>
>> -Korey
>>
>> On Fri, Aug 24, 2012 at 8:04 AM, Anthony Gutierrez
>> wrote:
>> > This is the part of the code where the committedInsts get's incremented,
>> > so
>> > it should match up with that and has nothing to do with the ops.
>> >
>> > -Tony
>> >
>> >
>> > On Fri, Aug 24, 2012 at 10:16 AM, Korey Sewell
>> > wrote:
>> >>
>> >> Tony,
>> >> check the nop count. That might be the difference that you are seeing.
>> >>
>> >> -Korey
>> >>
>> >> On Thu, Aug 23, 2012 at 1:24 PM, Anthony Gutierrez
>> >> wrote:
>> >> > Hello,
>> >> >
>> >> > It seems that the number of committed instructions don't always match
>> >> > up
>> >> > with an instruction-based exit event, e.g., when using -I. The CPU's
>> >> > number
>> >> > of committedInsts can sometime be a few more or less than this value.
>> >> > I
>> >> > think I understand why the number can be more, if an exit event is
>> >> > scheduled
>> >> > when commit commits its 1,000th instruction, other events scheduled
>> >> > for
>> >> > the
>> >> > same tick can cause more instructions to be committed. Is that
>> >> > correct?
>> >> > But,
>> >> > why can the number of committed instructions ever be less than the
>> >> > number
>> >> > that triggers an exit event? I added this to the O3 cpu and dumped
>> >> > and
>> >> > reset
>> >> > stats after every exit:
>> >> >
>> >> > //inside of instDone()
>> >> > if (!(thread[tid]->numInst % 1000))
>> >> > exitSimLoop("1000 insts reached", 0);
>> >> >
>> >> > The number of committedInsts dumped after each exit varies but it
>> >> > usually
>> >> > within a few % of 1,000. However, it is rarely ever 1,000.
>> >> >
>> >> > Thanks,
>> >> > Tony
>> >> >
>> >> > ___
>> >> > gem5-users mailing list
>> >> > gem5-users@gem5.org
>> >> > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>> >>
>> >>
>> >>
>> >> --
>> >> - Korey
>> >> ___
>> >> 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
>>
>>
>>
>> --
>> - Korey
>> ___
>> 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
--
- Korey
___
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Re: [gem5-users] 答复: ruby request latency and L1 miss rate
On Thu, 23 Aug 2012, Xi Chen wrote: Hi Nilay, Yes, I've taken a look at the ruby.stats file. I'm a little confused about some naming issues, like: Request_type_LD, request_type_ST and request_type_ATOMIC, what is the difference of them? These names seem self explanatory. LD stands for load, ST for store, ATOMIC for atomic read/modify/write requests. Also in the ruby.stats file, there is only average network latency which defined as: network_latency/flits_received. I want to find the request/packet latency sent out by L1 cache into the network. Actually I looked into the code like Sequencer.cc and port.cc, but still got no clue. In the file, you should find several histograms on miss latencies. -- Nilay ___ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Re: [gem5-users] segmentation fault when creating checkpoints for X86_FS+ruby
Hi Nilay, Thank you for your reply. I did debug it with gdb and it reported the assertion "assert(isDeadlockEventScheduled() == false)" in mem/ruby/system/RubyPort.cc was failed. I've no idea how to fix it but just commented this statement and compiled and ran again. It reported segmentation fault again because "build/X86/python/swig/pyevent.cc:84: void cleanupCountedDrain(Event*): Assertion `event->getCount() == 0' failed." I also tried to restore the checkpoints (they seemed to be created, at least there were checkpoint files in the directory) using the following command: build/X86/m5.debug -d ruby-output configs/example/ruby_fs.py --kernel=x86_64-vmlinux-2.6.22.9.smp --script=configs/boot/mcf.rcS --cpu-type=detailed --caches --ruby -r 4. But it failed and reported as: -- File "/home/ytian/Documents/Gem5/configs/common/Simulation.py", line 70, in setCPUClass class TmpClass(AtomicSimpleCPU): pass NameError: global name 'AtomicSimpleCPU' is not defined So I removed the option "--cpu-type" and used "--restore-with-cpu=detailed" to restore the checkpoint again. It reported as: --- File "/home/ytian/Documents/Gem5/configs/common/Simulation.py", line 45, in setCPUClass class TmpClass(TimingSimpleCPU): pass NameError: global name 'TimingSimpleCPU' is not defined I think both of the objects are defined. So I wonder if there is something wrong with the steps/options which I used to compile/run the gem5 since I didn't make any changes to the source code. Could you please help me fix this problem? Thank you for your help. Thanks, Yingying On Thu, Aug 23, 2012 at 11:53 AM, Nilay Vaish wrote: > Well, whenever I get a segmentation fault with any program, I run it under > GDB and figure out where the problem might be. In almost all the cases, > this works out well. You might also want to do the same. > > -- > Nilay > > > On Thu, 23 Aug 2012, Cookie wrote: > > To whom it may concern, >> >> I got segmentation fault when trying to create checkpoints for X86_FS with >> ruby. Hereunder are the steps, please tell me if there is anything wrong: >> >> 1/ Compile Gem5 with RUBY and MOESI_hammer protocol: >>$ scons -j4 build/X86/gem5.fast PROTOCOL=MOESI_hammer RUBY=True >> >> 2/ Writing the mcf.rcS script with the checkpoint command. Here is the >> script file: >> cd run/run_base_ref_x86. >> /sbin/m5 checkpoint 0 0 >> /sbin/m5 checkpoint 1 2 >> /sbin/m5 loadsymbol >> /sbin/m5 resetstats >> echo "i am reaching program itself" >> /spec06/429.mcf/exe/mcf_base.**exe inp.in >> /sbin/m5 exit >> >> 3/ Running the program: >> $ build/X86/gem5.fast -d ruby-output configs/example/ruby_fs.py >> --kernel=x86_64-vmlinux-2.6.**22.9.smp --script=configs/boot/mcf.rcS >> --cpu-type=detailed --caches --ruby --checkpoint-dir=checkpoint-**dir >> >> However, when it tried to write the checkpoint, it gave the following >> output and exited: >> --**--- >> info: Entering event queue @ 516496500. Starting simulation... >> Writing checkpoint >> Segmentation fault >> --**--- >> >> I also tried to create checkpoint using options like: --take-checkpoints >> "1000, 1000", which also encountered the segmentation fault and >> exited. Could you please tell me what the problem is? Did I give the wrong >> options or any steps missing? Thank you in advance. >> >> >> Thanks, >> Yingying >> >> ___ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Re: [gem5-users] Trouble booting O3CPU on X86 FS
Thanks Hao for the reply. So, are you booting the kernel with the o3cpu as well? There were a comment by one of the developers saying that people usually boot the system with an inorder cpu, take a checkpoint and then run their simulation using the o3cpu. Thanks, Mahshid On Tue, Aug 21, 2012 at 8:25 PM, Hao Wang wrote: > I extract revision 8930 and that works for x86 O3. > > Hao > > On Tue, Aug 21, 2012 at 5:28 PM, Mahshid Sedghi > wrote: > >> Hi there. >> >> I have a problem similar to the one discussed in the following: >> http://www.mail-archive.com/gem5-users@gem5.org/msg02407.html >> >> I am trying to boot a system with 16 out of order processors (of type >> "detailed") running an x86 ISA in full system mode. But when it boots the >> system, I get some warnings such as: >> >> warn: Address 0xffc0 is outside of physical memory, stopping fetch >> >> and the booting process gets aborted because a failed assertion: >> >> gem5.opt: build/X86/cpu/o3/fetch.hh:105: void >> DefaultFetch::FetchTranslation::finish(Fault, Request*, >> ThreadContext*, BaseTLB::Mode) [with Impl = O3CPUImpl]: Assertion `mode == >> BaseTLB::Execute' failed. >> >> Could anyone help me figure out a solution? >> >> Thanks, >> Mahshid >> >> >> >> ___ >> gem5-users mailing list >> gem5-users@gem5.org >> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >> > > > > -- > -- > Wang, Hao > http://homepages.cae.wisc.edu/~wangh/ > > Ph.D. candidate > Dept. of Electrical & Computer Engineering > University of Wisconsin, Madison > > B.S. from > Department of Microelectronics > School of Electronics Engineering and Computer Science > Peking University > > > ___ > 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
Re: [gem5-users] Segmentation fault running MOESI_CMP_token protocol with more than 128 cores in X86 SE
On Fri, 24 Aug 2012, gem5 gem5 wrote:
Hi ,
I run GEM5 with MOESI_CMP_token protocol for any cores below 128, it works
well. However, when I run it with more than 128 cores, I get segmentation
fault:
command line: build/X86_SE/gem5.opt configs/example/ruby_random_test.py
--num-cpus=130 --num-dirs=1 --topology=Pt2Pt
Global frequency set at 10 ticks per second
info: Entering event queue @ 0. Starting simulation...
Segmentation fault
I have tried Pt2Pt topology and Crossbar, it's the same error.
Then I used gdb and program stopped here:
Program received signal SIGSEGV, Segmentation fault.
0x00b3a536 in Address::getAddress (this=0x2)
at build/X86_SE/mem/ruby/common/Address.hh:61
61physical_address_t getAddress() const {return m_address;}
I think you should use gdb to print the call stack and figure why this
Address Object is being accessed, when the object has not been allocated
in first place.
--
Nilay
___
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Re: [gem5-users] Segmentation fault running MOESI_CMP_token protocol with more than 128 cores in X86 SE
Hi Nilay,
I got the callback information as follows. It seems to me that there is
some address in Directory Entry got accessed but not allocated. But I dont
know whyCan you please help me interpret this? thanks!
Best,
Jinzhu
command line:build/X86_SE/gem5.debug configs/example/ruby_random_test.py
--num-cpus=130 --num-dirs=1 --topology=Pt2Pt
Global frequency set at 10 ticks per second
info: Entering event queue @ 0. Starting simulation...
Program received signal SIGSEGV, Segmentation fault.
0x00b3a536 in Address::getAddress (this=0x2)
at build/X86_SE/mem/ruby/common/Address.hh:61
61 physical_address_t getAddress() const {return m_address;}
(gdb) where
#0 0x00b3a536 in Address::getAddress (this=0x2)
at build/X86_SE/mem/ruby/common/Address.hh:61
#1 0x00b3a567 in operator== (obj1=..., obj2=...)
at build/X86_SE/mem/ruby/common/Address.hh:120
#2 0x00b3a5b9 in std::equal_to::operator()
(this=0xa3d4451, s1=..., s2=...)
at build/X86_SE/mem/ruby/common/Address.hh:222
#3 0x00c1aaed in std::tr1::__detail::_Hash_code_base >,
std::_Select1st > >, std::equal_to,
std::tr1::hash, std::tr1::__detail::_Mod_range_hashing,
std::tr1::__detail::_Default_ranged_hash, false>::_M_compare (this=
0xa3d4450, __k=..., __n=0x2) at
/usr/include/c++/4.5/tr1/hashtable_policy.h:684
#4 0x00c1a4d7 in std::tr1::_Hashtable >,
std::allocator > >,
std::_Select1st > >, std::equal_to,
std::tr1::hash, std::tr1::__detail::_Mod_range_hashing,
std::tr1::__detail::_Default_ranged_hash,
std::tr1::__detail::_Prime_rehash_policy, false, false, true>::count
(this=0xa3d4450, __k=...) at /usr/include/c++/4.5/tr1/hashtable.h:731
#5 0x00c1a1a6 in
PerfectCacheMemory::isTagPresent (this=0xa3d4450,
address=...)
at build/X86_SE/mem/ruby/system/PerfectCacheMemory.hh:121
#6 0x00c19849 in L2Cache_Controller::setNewWriter (this=0x38fd000,
param_addr=...,
param_id=@0x7fffc11c) at
build/X86_SE/mem/protocol/L2Cache_Controller.cc:1836
#7 0x00c15615 in L2Cache_Controller::r_markNewSharer
(this=0x38fd000,
m_cache_entry_ptr=@0x7fffc3b8, addr=...)
at build/X86_SE/mem/protocol/L2Cache_Controller.cc:1343
#8 0x00c21a15 in L2Cache_Controller::doTransitionWorker
(this=0x38fd000,
event=L2Cache_Event_L1_GETX, state=L2Cache_State_I_L,
next_state=@0x7fffcb10,
m_cache_entry_ptr=@0x7fffc3b8, addr=...)
at build/X86_SE/mem/protocol/L2Cache_Transitions.cc:117
#9 0x00c1fa8d in L2Cache_Controller::doTransition (this=0x38fd000,
event=L2Cache_Event_L1_GETX, m_cache_entry_ptr=0x0, addr=...)
at build/X86_SE/mem/protocol/L2Cache_Transitions.cc:38
#10 0x00c261bb in L2Cache_Controller::wakeup (this=0x38fd000)
at build/X86_SE/mem/protocol/L2Cache_Wakeup.cc:283
#11 0x00b374fd in RubyEventQueueNode::process (this=0x8599320)
at build/X86_SE/mem/ruby/eventqueue/RubyEventQueueNode.hh:51
#12 0x00e8d106 in EventQueue::serviceOne (this=0x1f6ed40)
at build/X86_SE/sim/eventq.cc:204
#13 0x00ed0f74 in simulate (num_cycles=9223372036854775807)
at build/X86_SE/sim/simulate.cc:73
#14 0x00ddb460 in _wrap_simulate__SWIG_0
(args=(9223372036854775807L,))
at build/X86_SE/python/swig/event_wrap.cc:4488
#15 0x00ddb61d in _wrap_simulate (self=0x0,
args=(9223372036854775807L,))
at build/X86_SE/python/swig/event_wrap.cc:4538
#16 0x773af0b1 in ext_do_call (f=,
throwflag=)
at ../Python/ceval.c:4323
#17 PyEval_EvalFrameEx (f=, throwflag=)
at ../Python/ceval.c:2705
#18 0x773b127d in PyEval_EvalCodeEx (co=0x2c3d4b0, globals=,
locals=, args=, argcount=1,
kws=0x35ab3a8,
kwcount=0, defs=0x0, defcount=0, closure=0x0) at ../Python/ceval.c:3253
#19 0x773af28d in fast_function (f=,
throwflag=) at ../Python/ceval.c:4109
#20 call_function (f=, throwflag=)
---Type to continue, or q to quit---
at ../Python/ceval.c:4034
#21 PyEval_EvalFrameEx (f=, throwflag=)
at ../Python/ceval.c:2666
#22 0x773b127d in PyEval_EvalCodeEx (co=0x34371b0, globals=,
locals=, args=, argcount=0,
kws=0x0, kwcount=0,
defs=0x0, defcount=0, closure=0x0) at ../Python/ceval.c:3253
#23 0x773b1392 in PyEval_EvalCode (co=,
globals=, locals=) at
../Python/ceval.c:667
#24 0x773b0228 in exec_statement (f=,
throwflag=) at ../Python/ceval.c:4710
#25 PyEval_EvalFrameEx (f=, throwflag=)
at ../Python/ceval.c:1880
#26 0x773b127d in PyEval_EvalCodeEx (co=0x2c80030, globals=,
locals=, args=, argcount=0,
kws=0x2ca2620,
kwcount=0, defs=0x0, defcount=0, closure=0x0) at ../Python/ceval.c:3253
#27 0x773af28d in fast_function (f=,
throwflag=) at ../Python/ceval.c:4109
#28 call_function (f=, throwflag=)
at ../Python/ceval.c:4034
#29 PyEval_EvalFrameEx (f=, throwflag=)
at ../Python/ceval.c:2666
#30 0x773b127d in PyEval_EvalCodeEx (co=0x2cc8d30, globals=,
locals=, args=, argcount=0,
kws=
[gem5-users] adding a stat at the end of the simulation
Hi, I am running a gem5 with some external simulator glued to it. I would like to have a single stats.txt file that also has stats from the external simulator. At first, I tried to pull the stats from the external simulator, and new Stat::Scalar()ed for each one of them, hoping that they register and print the values. It didn't work. After further digging, The python/m5/stats/__init__py has a comment says "def enable(): '''Enable the statistics package. Before the statistics package is enabled, all statistics must be created and initialized and once the package is enabled, no more statistics can be created.''' == you can't add stats once the simulation starts. So now I plan to new Stat::Scalar() in the regStats() to register external simulator stats, then later update the value when the simulator ends. If anybody had done something like this, and had a better way to handle this situation, please share. Thanks, Min ___ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Re: [gem5-users] adding a stat at the end of the simulation
You probably want a Stats::Value and set the functor() to a function that returns the stat. That functor will be called when the stats are dumped. Ali On 24.08.2012 19:29, Min Kyu Jeong wrote: > Hi, > > I am running a gem5 with some external simulator glued to it. I would like to have a single stats.txt file that also has stats from the external simulator. > At first, I tried to pull the stats from the external simulator, and new Stat::Scalar()ed for each one of them, hoping that they register and print the values. It didn't work. > > After further digging, > > The python/m5/stats/__init__py has a comment says > > "def enable(): > '''Enable the statistics package. Before the statistics package is > enabled, all statistics must be created and initialized and once > the package is enabled, no more statistics can be created.''' > > == you can't add stats once the simulation starts. > > So now I plan to new Stat::Scalar() in the regStats() to register external simulator stats, then later update the value when the simulator ends. If anybody had done something like this, and had a better way to handle this situation, please share. > > Thanks, > > Min ___ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
[gem5-users] How do I run multiprogram workloads on M5?
I saw the following answer in FAQ: "In SE mode, simply create a system with
multiple CPUs and assign a different workload object to each CPU's workload
parameter. If you're using the O3 model, you can also assign a vector of
workload objects to one CPU, in which case the CPU will run all of the
workloads concurrently in SMT mode."
I see a program line in se.py as:
if options.cpu_type == "detailed" or options.cpu_type == "inorder":
#check for SMT workload
workloads = options.cmd.split(';')
it looks like the separator is a semi-colon (;)
how do I assign different workload to each CPU? is it by running se.py with
the following options
--cmd=benchmark1 --options=option1; --cmd=benchmark2 --options=option2
doing this it ignore anything after the semi-colon
or
--cmd=benchmark1;benchmark2 --options=option1;option2
any idea?
Thanks
___
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
