Mr. Ali, This was the output on the terminal: cpu 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 boot Boot device: vdisk File and args: 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 Copyright 1983-2005 Sun Microsystems, Inc. All rights reserved. Use is subject to license terms. Hostname: unknown unknown console login: The last time I ran the simulation, before I could enter the console login, the simulation terminated. When I ran the same script with the ALPHA binary, it booted linux and I could try commands on the terminal and I had to explicitly terminate the simulation. Hence, I was expecting the same behaviour in SPARC_FS too. From what you said, I guess I would have to modify the script to ensure that there is something to do. 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
