It's probably failing because the hypervisor and open boot binaries are slightly different. I imagine it's working fine.
Ali On Wed, 24 Feb 2010 00:21:37 +0530, prasun gera <[email protected]> wrote: > 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
