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
