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
