Now, after using a modified solaris image, the regression is running
as expected as far as I can see. i.e The last line on simout is
Exiting @ tick 2222503770 because m5_exit instruction encountered,
which means that it is running the halt script after booting solaris.
However, on the terminal, the regression ends with
*****
build/SPARC_FS/tests/opt/long/80.solaris-boot/sparc/solaris/t1000-simple-atomic
FAILED!
It prints all the output differences from the reference directory
which mainly include differenecs in paths and versions. I can post the
diff if its relevant. After the diff, the last few lines of the output
were:
scons: *** Error 1
===== Statistics differences =====
Maximum error magnitude: +0.504705%
Reference New Value Abs Diff Pct Chg
Key statistics:
host_inst_rate 2338829 883942 -1454887 -62.21%
host_mem_usage 501616 424220 -77396 -15.43%
sim_insts 2229160714 2217967932 -11192782 -0.50%
sim_ticks 2233777512 2222503770 -11273742 -0.50%
Largest 20 relative errors (> 0%):
sim_insts 2229160714 2217967932 -11192782 -0.50%
sim_seconds 1.116889 1.111252 -0.005637 -0.50%
sim_ticks 2233777512 2222503770 -11273742 -0.50%
system.cpu.numCycles 2233777513 2222503771 -11273742 -0.50%
system.cpu.num_insts 2229160714 2217967932 -11192782 -0.50%
system.cpu.num_refs 547951940 546386922 -1565018 -0.29%
*****
build/SPARC_FS/tests/opt/long/80.solaris-boot/sparc/solaris/t1000-simple-atomic
FAILED!
scons: done building targets.
I couldn't find any specific error in the output. Is it failing
because of some difference from the reference? Can this be ignored?
On Sun, Feb 21, 2010 at 2:46 AM, Ali Saidi <[email protected]> wrote:
> I guess I must have modified the disk image to support the m5 style runfile
> command. The trouble is I don't think we can distribute a modified solaris
> disk image.
>
>
>
> Ali
>
>
>
> On Feb 19, 2010, at 2:23 PM, prasun gera wrote:
>
>> And while running fs.py, after entering the login, the simulation
>> lasted for 5 minutes or so, which is more than earlier, before
>> terminating at max_tick. If there is a way around the solaris prompt,
>> please let me know.
>>
>> On Fri, Feb 19, 2010 at 6:22 PM, prasun gera <[email protected]>
>> wrote:
>>>
>>> Hi Ali,
>>> Now, after updating nvram1, the first problem is resolved. i.e. opb
>>> boots automatically. However, the regression gets stuck at the solaris
>>> login prompt. The terminal output in the reference directory is
>>> ....
>>> ....
>>> iscsi0 at root
>>> iscsi0 is /iscsi
>>> Hostname: unknown
>>> Loading M5 readfile script...
>>>
>>> whereas my output is
>>> .....
>>> .....
>>> iscsi0 at root
>>> iscsi0 is /iscsi
>>> Hostname: unknown
>>> ^M
>>> unknown console login:
>>>
>>> So, I suppose the login also needs to be automated.
>>>
>>> On Fri, Feb 19, 2010 at 1:31 AM, Ali Saidi <[email protected]> wrote:
>>>>
>>>> There is no facility built into M5 to do this. You could do something to
>>>> copy the data out after you write it (the file is just loaded into RAM),
>>>> or
>>>> you could use the functional simulation from the that came with the
>>>> images
>>>> to modify the file and save it.
>>>>
>>>> Ali
>>>>
>>>>
>>>>
>>>>
>>>> On Fri, 19 Feb 2010 01:11:56 +0530, prasun gera <[email protected]>
>>>> wrote:
>>>>>
>>>>> I tried setting auto-boot? true with the following command:
>>>>> setenv auto-boot? true
>>>>> However, it sets the value only for the current session and doesn't
>>>>> last after i restart the simulation. Is there a way around?
>>>>>
>>>>> On Thu, Feb 18, 2010 at 4:47 AM, prasun gera <[email protected]>
>>>>
>>>> wrote:
>>>>>>
>>>>>> Yes, I had used boot as the boot string and it used to boot solaris.
>>>>>> i.e It used to boot till the terminal stopped at the following prompt:
>>>>>> ....
>>>>>> ....
>>>>>> Loading: /platform/SUNW,Sun-Fire-T2000/ufsboot
>>>>>> Loading: /platform/sun4v/ufsboot
>>>>>>
>>>>>> Copyright 1983-2005 Sun Microsystems, Inc. All rights reserved.
>>>>>> Use is subject to license terms.
>>>>>> Hostname: unknown
>>>>>> unknown console login:
>>>>>>
>>>>>> At this prompt, the couple of times when I was quick enough, I could
>>>>>> enter root as the login and I could see the solaris promt, shortly
>>>>>> after which m5 used to exit. At other times,
>>>>>> m5 would just quit at the 'unknown console login' prompt. Can you tell
>>>>>> me where I need to change the boot settings for it to boot
>>>>>> automatically? Also, does the console login string need to be passed
>>>>>> automatically? Or is it normal to enter it manually?
>>>>>>
>>>>>> Thanks,
>>>>>> Prasun
>>>>>>
>>>>>> On Thu, Feb 18, 2010 at 4:21 AM, Ali Saidi <[email protected]> wrote:
>>>>>>>
>>>>>>> If your previous simulations were sitting at the ok prompt, that
>>>>>>> would
>>>>>>> explain it. The settings aren't compile in, but rather are saved into
>>>>>>> the
>>>>>>> nvram blob that is loaded. If you connect to the simulator and
>>>>>>> provide
>>>>
>>>> a
>>>>>>>
>>>>>>> proper boot string (I can't remember what one is, maybe just boot),
>>>>
>>>> does
>>>>>>>
>>>>>>> it
>>>>>>> boot into Solaris?
>>>>>>>
>>>>>>> Ali
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Thu, 18 Feb 2010 03:33:36 +0530, prasun gera
>>>>>>> <[email protected]>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> I'm running the solaris boot regression test right now with the
>>>>
>>>> command
>>>>>>>>
>>>>>>>> line
>>>>>>>> scons build/SPARC_FS/tests/opt/long/80.solaris-boot
>>>>>>>> but it seems to be stuck since openboot expects a manual boot
>>>>>>>> command.
>>>>>>>> My system.t1000.pterm shows:
>>>>>>>> ^Qcpu Probing I/O buses
>>>>>>>>
>>>>>>>>
>>>>>>>> Sun Fire T2000, No Keyboard
>>>>>>>> Copyright 2005 Sun Microsystems, Inc. All rights reserved.
>>>>>>>> OpenBoot 4.20.0, 256 MB memory available, Serial #1122867.
>>>>>>>> [mo23723 obp4.20.0 #0]
>>>>>>>> Ethernet address 0:80:3:de:ad:3, Host ID: 80112233.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ok
>>>>>>>>
>>>>>>>> where I used to enter the boot command at the ok prompt while
>>>>>>>> running
>>>>>>>> fs.py.
>>>>>>>> However, the corresponding file in the reference directory shows
>>>>>>>> ^Qcpu
>>>>>>>>
>>>>>>>> Sun Fire T2000, No Keyboard
>>>>>>>> Copyright 2006 Sun Microsystems, Inc. All rights reserved.
>>>>>>>> OpenBoot 4.23.0, 256 MB memory available, Serial #1122867.
>>>>>>>> [saidi obp #30]
>>>>>>>> Ethernet address 0:80:3:de:ad:3, Host ID: 80112233.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Boot device: /virtual-devices/d...@0 File and args: -vV
>>>>>>>> Loading ufs-file-system package 1.4 04 Aug 1995 13:02:54.
>>>>>>>> FCode UFS Reader 1.12 00/07/17 15:48:16.
>>>>>>>> Loading: /platform/SUNW,Sun-Fire-T2000/ufsboot
>>>>>>>> Loading: /platform/sun4v/ufsboot
>>>>>>>> ......
>>>>>>>> ......
>>>>>>>>
>>>>>>>> It seems to me that the openboot binary you used for the regression
>>>>>>>> was configured to autoboot. Do I need to recompile openssparc t1
>>>>>>>> with
>>>>>>>> openboot configured for autoboot? Also, does this explain my
>>>>>>>> earlier
>>>>>>>> problem of m5 exiting at max_tick?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Prasun
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Feb 17, 2010 at 9:17 PM, Ali Saidi <[email protected]> wrote:
>>>>>>>>>
>>>>>>>>> Can you run the SPARC_FS regression successfully?
>>>>>>>>>
>>>>>>>>> Ali
>>>>>>>>>
>>>>>>>>> On Feb 16, 2010, at 8:11 PM, prasun gera wrote:
>>>>>>>>>
>>>>>>>>>> Forgot that I edited a cc file and not a script and hence didn't
>>>>>>>>>> rebuild. I suppose this won't happen once i rebuild m5.
>>>>>>>>>>
>>>>>>>>>> On Wed, Feb 17, 2010 at 7:19 AM, prasun gera
>>>>>>>>>> <[email protected]>
>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> 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
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> 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
