Hi Ali, So now the regression seems to be working fine, and I can carry on with further experimentation. However, when I tried to run fs.py, m5 still waits for login input and quits after at max_tick. The terminal output was : ...... iscsi0 is /iscsi Hostname: unknown Loading M5 readfile script... Script from M5 readfile is empty... ^M unknown console login:
The main difference is that now it loads the readfile script. So although working in an interactive terminal might not be possible yet, I can, for example, specify the execution of binaries on disk in the script and it will execute them before exiting right? Also, I tried to use the timing model by passing -t to fs.py. It fails with with the following assert: m5.opt: build/SPARC_FS/cpu/simple/timing.cc:870: void TimingSimpleCPU::completeDataAccess(Packet*): Assertion `!pkt->isError()' failed. I still need to probe further to find out what is causing the error. I have a more general question though. I'm trying to use SPARC_FS (as opposed to alpha fs) because I'm interested in doing some experiments and measurements related to the performance of the Intel TBB library. Officially TBB supports only x86, with support for SPARC in the form of a patch written by a user, leaving SPARC_FS the only option in m5. In particular, I am interested in simulating a NUMA sytem. I found a mail thread which mentions a patch written by Jiayuan Meng to achieve a 2d mesh interconnection network. However, regarding sparc fs, the wiki says 'M5 models a single core of a UltraSPARC T1 processor with sufficient detail to boot Solaris'. So I couldn't quite assess how difficult it'll be to achieve the desired target numa system with sparc fs. If you can outline the main obstacles or gaps that i would face in sparc fs, it'll help me a lot in making a decision. The other alternative it porting TBB to alpha, which isn't trivial either. Thanks, Prasun > > 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
