Ali,
I saw the simulate(Tick num_cycles) function in
build/SPARC_FS/sim/simulate.cc and it has the following lines of code
(lines 58 to 60)
Event *limit_event =
new SimLoopExitEvent("simulate() limit reached", 0);
mainEventQueue.schedule(limit_event, num_cycles);
As far as I can tell, this is the only place where a limit_event is
added to the event queue. (and should be the only one right?) So I
commented the aforementioned lines out just to see what happens.
However, m5 still exit with same error message about limit being
reached. I expected m5 to exit with an assert failure(inside the
following while loop) since the queue would be empty after the event
before the limit_event is executed, but that didn't happen. So does
it mean that another(possibly interfering) limit_event was added to
the queue earlier?
Thanks,
Prasun
On Mon, Feb 15, 2010 at 3:08 AM, Ali Saidi <[email protected]> wrote:
> Prasun,
>
> I imagine what is happening is you're running the simple cpu, booting
> Solaris and then there is nothing to do, since you didn't specify
> anything. The only think that occurs after that point are timer
> interrupts which makes the simulation tick quite quickly up until you
> reach MaxTick. Have you looked at the terminal? What is the output
> there?
>
> Ali
>
> On Feb 14, 2010, at 2:33 PM, prasun gera wrote:
>
>> Hi,
>> You mentioned that I'm using the O3 CPU model. Isn't the default model
>> simple atomic? I mean, I didn't pass any arguments to the script fs.py
>> and from setCPUClass, it seemed as though it is using the simple
>> atomic model.
>> In fact, later I tried the command line
>>
>> build/SPARC_FS/m5.opt -v -d /tmp/output/ configs/example/fs.py -d --
>> caches
>>
>> to use the detailed CPU model but it threw an error
>> NameError: global name 'DerivO3CPU' is not defined.
>>
>>
>> On Sat, Feb 13, 2010 at 6:56 AM, Gabriel Michael Black
>> <[email protected]> wrote:
>>> It looks like the simulation ran out of things to do and stopped at
>>> the end of simulated time. You could use the Exec trace flag to see
>>> what, if anything, is executing when that happens. If the simulation
>>> runs for a while before failing, Exec will output a lot of text.
>>> You'll want to start tracing close to the interesting point.
>>>
>>> One other thing I notice is that you're using the O3 CPU model with
>>> SPARC_FS. While that model should work with SPARC_SE and SPARC_FS
>>> works with the simple CPUs, I don't know if anyone ever got the bugs
>>> worked out of that particular combination (someone please say
>>> something if you know otherwise). That makes me think that O3 is
>>> losing track of work that it needs to do, thinks it should become
>>> idle, and effectively goes to sleep and never wakes up.
>>>
>>> Gabe
>>>
>>> Quoting prasun gera <[email protected]>:
>>>
>>>> I could boot solaris in SPARC_FS, but m5 exited abruptly after that
>>>> with the following message:
>>>> Exiting @ cycle 9223372036854775807 because simulate() limit reached
>>>>
>>>> The command line I executed was:
>>>> build/SPARC_FS/m5.opt -v -d /tmp/output/ configs/example/fs.py
>>>>
>>>> Host system: Ubuntu 32 bit
>>>>
>>>> I tried it twice, and it quit at the same cycle count both the
>>>> times.
>>>> To ascertain whether the error was caused because of something I
>>>> did,
>>>> I didn't enter anything on the solaris terminal the second time.
>>>> i.e.
>>>> The computer was idle for the entire duration except for the boot
>>>> command on opb. Has anyone run into a similar error? Or any hints
>>>> regarding debugging this?
>>>>
>>>>
>>>> On Fri, Feb 12, 2010 at 10:26 PM, Ali Saidi <[email protected]> wrote:
>>>>>
>>>>> The original binaries should work just fine, the _new versions
>>>>> were ones
>>>>> that we verified we could compile from source.
>>>>>
>>>>> Ali
>>>>>
>>>>>
>>>>> On Fri, 12 Feb 2010 20:50:07 +0530, prasun gera <[email protected]
>>>>> >
>>>>> wrote:
>>>>>> Figured it out. Copied the files to the binaries and disks
>>>>>> directories
>>>>>> and could run configs/example/fs.py after that. One small thing
>>>>>> though. The names of the solaris binaries used in m5 have new as a
>>>>>> suffix ( for eg. openboot_new.bin and q_new.bin). Does it mean
>>>>>> that
>>>>>> the original binaries from opensparc need to be modified in some
>>>>>> way?
>>>>>> _______________________________________________
>>>>>> m5-users mailing list
>>>>>> [email protected]
>>>>>> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
>>>>> _______________________________________________
>>>>> m5-users mailing list
>>>>> [email protected]
>>>>> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
>>>>>
>>>> _______________________________________________
>>>> m5-users mailing list
>>>> [email protected]
>>>> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
>>>>
>>>
>>>
>>> _______________________________________________
>>> m5-users mailing list
>>> [email protected]
>>> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
>>>
>> _______________________________________________
>> m5-users mailing list
>> [email protected]
>> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
>>
>
> _______________________________________________
> m5-users mailing list
> [email protected]
> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
>
_______________________________________________
m5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
