Re: [m5-dev] [m5-users] 01.hello-2T-smt on SPARC
Hi, well if you are interested in doing a some debugging you can start to uncover the problem. So that probably would signal this conversation go to the m5-dev list instead of m5-users (I think at least). If I were you, these would be my steps to figure out the problem. (1) Run a Sparc Hello World on AtomicSimpleCPU with tracing on. Trace the instructions "Exec". (2) Do the same trace on a 2T-Hello World Sparc. (3) Diff the trace for each thread against your "golden model" Sparc Hello World (you can use some of the M5 preloaded scripts like util/tracediff) More than likely, you'll see one of the threads stop committing instructions at some point. Once you find where the breaking point is for your SMT threads, you can re-run your code with other traceflags to figure out what's happening (O3CPUAll). I'm not familiar with SPARC but more than likely a problem with speculation and register windows messes up the assignments some way. Anyway, that's the path I would take to finding the bug fix. Not exactly "easy" but definitely "doable". Hope that helps... On Mon, Jul 13, 2009 at 9:19 PM, soumyaroop roy wrote: > Thanks, Gabe. My comments are embedded in your reply. > > On Mon, Jul 13, 2009 at 8:57 PM, Gabriel Michael Black > wrote: >> >> There are a few problems with doing things this way. First, there are no >> guarantees that SMT is supported for SPARC on O3 as far as I know. Someone >> with more experience with O3 and SMT would have to comment there, but the >> fact that there are no regressions for it suggests that it's at least >> untested. > > It appears to me that making smt work for sparc should not be a lot of work. > Most of the code CPU modeling is ISA independent. If someone could give me > some directions, I should be able to get this working pretty quickly. Please > correct me if I am wrong though. > >> >> Second, I don't know if all the binaries that regression needs are going >> to be available for SPARC. If it just uses the "hello" binary then that >> might work out. > > That is correct. "hello" is the binary that is used. > >> >> Third, if the binary exists and runs correctly, copying the reference >> outputs from alpha to sparc will almost certainly not be what you want. The >> many detailed statistics O3 tracks will definitely change when a completely >> different binary compiled for another architecture is used. > > I agree with you completely here. I should correct one of the statements > that I made in my last email. I made a copy of the test for the "test.py" > script that instantiates the workloads (and not for the gold outputs). > > regards, > Soumyaroop. > >> >> >> Quoting soumyaroop roy : >> >>> Thanks for your replies. >>> >>> All I did were the following (from ): >>> >>> 1. Made a copy of the test (although this appears to serve only as gold >>> ouputs): >>> % cp -r tests/quick/01.hello-2T-smt/ref/alpha >>> tests/quick/01.hello-2T-smt/ref/sparc >>> >>> 2. Ran the testcase: >>> % scons build/SPARC_SE/tests/fast/quick/01.hello-2T-smt >>> >>> What steps should I take to debug this further? >>> >>> regards, >>> Soumyaroop. >>> >>> On Mon, Jul 13, 2009 at 8:20 PM, Steve Reinhardt >>> wrote: >>> It's also a sign of a deadlock... perhaps there's a deadlock situation that's not covered by the assertion. Steve On Mon, Jul 13, 2009 at 3:31 PM, Cong Wang wrote: > The error suggests that you do not have anything on the main event > queue. Please check if you are making the proper call to schedule > events correctly on the main event queue. > > Regards > James Wang > > On Mon, Jul 13, 2009 at 3:12 PM, soumyaroop roy > wrote: > > Hello all, > > > > I tried to run the testcase 01.hello-2T-smt for SPARC without > > increasing > the > > number of physical registers (in o3-timing.py script) and I was > > hoping > to > > see an assertion failure because of the following statement in > > cpu.cc: > > assert(params->numPhysIntRegs >= numThreads * TheISA::NumIntRegs); > > > > However, I get no such failure. Instead, I get this error: > > "Exiting @ tick 9223372036854775807 because simulate() limit reached" > > > > Here are the contents of simout (numThreads and TheISA::NumIntRegs > > are > also > > printed out): > > > M5 Simulator System > > > > Copyright (c) 2001-2008 > > The Regents of The University of Michigan > > All Rights Reserved > > > > > > M5 compiled Jul 13 2009 16:27:20 > > M5 revision 94c016415053+ 6283+ default tip > > M5 started Jul 13 2009 18:03:38 > > M5 executing on theoracle > > command line: build/SPARC_SE/m5.fast -d > > build/SPARC_SE/tests/fast/quick/01.hello-2T-smt/sparc/linux/o3-timing > -re > > tests/run.py > > build/SPARC_SE/tests/fast/quick/01.hello-2T-smt/sparc/linux/o3-timing > > Global frequency set at 1 ticks per second > > n
Re: [m5-dev] Gem5 configuration
I believe there are only a few (maybe one?) case(s) where the Ruby initialization dependencies are pretty ugly. The one I know about is a dependency between the Ruby network and the topology class. Given the limited scope of the problem, I think Steve's null init function should suffice. -Derek On Mon, Jul 13, 2009 at 7:19 PM, Steve Reinhardt wrote: > There's no real control over ordering... I believe init() is called on > objects in the same order that they were constructed, but you don't have a > lot of control over the construction order (short of the fact that if B is a > parameter to A then B will be constructed first) and it's probably best not > to rely on that anyway. > > There are ways to fix this that we've discussed in the past, but we never > implemented any of them. If there's a real need we could do that. However, > there are a couple of other approaches that are simpler if they apply. Say > for example that B's initialization needs some information from A: > > - Does B need A to be fully initialized, or does it just need to acquire > some basic information? In the latter case, as long as A can do enough in > its constructor to keep B::init() happy, then that will just work since > B::init() won't be called until after all the objects have been created. I > know Nate won't like this, and it is a bit fragile since some later person > who adds more complex calls to A in B::init() might be surprised, but a more > pragmatic programmer might be content with putting appropriate comments in > A::A() and B::init() to head off that scenario. > > - Are there are just one or a few special cases of 1:1 dependencies? If so, > I'd be tempted to defer B's initialization to a separate method, i.e., > B::init() could be a no-op, then at the end of A::init() call B::postAInit() > and of course at that point you know A::init() is done. > > If the dependencies are more general (e.g., there are a bunch of As that all > have to be fully initialized before any of a bunch of Bs) then we can look > at other solutions; if that's the case, please provide some more details on > just what the constraints are. It's also possible that perhaps it's the > partitioning of concepts into SimObjects that needs to be tweaked. For > example, off the top of my head it's not clear why "topology" would be a > SimObject, since SimObjects are generally fairly concrete things you could > point to on a block diagram. > > Steve > > On Mon, Jul 13, 2009 at 3:21 PM, Somayeh Sardashti > wrote: >> >> Hi, >> >> Does M5 keep any order when calling init() of different objects? >> >> In Ruby, because of dependencies among some objects (like topology and >> network), the order of calling init() is important and handled in >> constructor of System (the main module). >> >> How can I keep this kind of ordering in M5? >> >> Somayeh > > > ___ > m5-dev mailing list > m5-dev@m5sim.org > http://m5sim.org/mailman/listinfo/m5-dev > > ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Gem5 configuration
There's no real control over ordering... I believe init() is called on objects in the same order that they were constructed, but you don't have a lot of control over the construction order (short of the fact that if B is a parameter to A then B will be constructed first) and it's probably best not to rely on that anyway. There are ways to fix this that we've discussed in the past, but we never implemented any of them. If there's a real need we could do that. However, there are a couple of other approaches that are simpler if they apply. Say for example that B's initialization needs some information from A: - Does B need A to be fully initialized, or does it just need to acquire some basic information? In the latter case, as long as A can do enough in its constructor to keep B::init() happy, then that will just work since B::init() won't be called until after all the objects have been created. I know Nate won't like this, and it is a bit fragile since some later person who adds more complex calls to A in B::init() might be surprised, but a more pragmatic programmer might be content with putting appropriate comments in A::A() and B::init() to head off that scenario. - Are there are just one or a few special cases of 1:1 dependencies? If so, I'd be tempted to defer B's initialization to a separate method, i.e., B::init() could be a no-op, then at the end of A::init() call B::postAInit() and of course at that point you know A::init() is done. If the dependencies are more general (e.g., there are a bunch of As that all have to be fully initialized before any of a bunch of Bs) then we can look at other solutions; if that's the case, please provide some more details on just what the constraints are. It's also possible that perhaps it's the partitioning of concepts into SimObjects that needs to be tweaked. For example, off the top of my head it's not clear why "topology" would be a SimObject, since SimObjects are generally fairly concrete things you could point to on a block diagram. Steve On Mon, Jul 13, 2009 at 3:21 PM, Somayeh Sardashti wrote: > Hi, > > Does M5 keep any order when calling init() of different objects? > > In Ruby, because of dependencies among some objects (like topology and > network), the order of calling init() is important and handled in > constructor of System (the main module). > > How can I keep this kind of ordering in M5? > > Somayeh > ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] wiki updated
I just updated the wiki software to the latest version. If anyone notices some problems please let me know. Thanks, Ali ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Gem5 configuration
Hi, Does M5 keep any order when calling init() of different objects? In Ruby, because of dependencies among some objects (like topology and network), the order of calling init() is important and handled in constructor of System (the main module). How can I keep this kind of ordering in M5? Somayeh Gabriel Michael Black wrote: > Quoting nathan binkert : > >>> - You're guaranteed that any SimObject that is passed to you as a parameter >>> has been constructed before your constructor is called, so that the pointer >>> in the params struct is valid. Since init() hasn't been called yet you >>> can't assume too much about what that other object is prepared to do >>> though. If you need to do something that relies on the other object having >>> been through init(), you need to do it in startup(). Note that this means >>> you can't have circular parameter dependencies. Basically if you have two >>> objects A and B that need to know about each other (other than being >>> connected via a port), there's a special relationship, and one of them will >>> have a "register" method. So for example A will get a pointer to B, but >>> then in A's constructor or init() method it will call B->registerA() to say >>> "hey B, I'm your A". >> Are you sure that this is guaranteed? I know we've gone back and >> forth about this and circular dependencies and whether we support >> them. Maybe we don't support them yet. (Though we could) >> >>> As always, the source is the ultimate guide; since Nate moved a lot of this >>> into python I had to do some searching to find it myself. See >>> src/python/sim/simulate.py and realize that a number of the functions that >>> get called there are actually C++ functions wrapped via SWIG. >> Construction and init() are called from m5.instantiate() startup() >> is called the first time that simulate() is called. >> >>> If anyone (Nate?) has some more specific guidelines on how things should be >>> split conceptually between the constructor, init(), and startup() please >>> speak up. >> I think that the general rule of thumb should be that constructors can >> use *non* SimObject parameters. >> >> init() should use SimObject parameters. I could create a proxy object >> to wrap SimObject parameters to assert() that things are done >> correctly. >> >> startup() should be for stuff that is dependent on happening *after* >> resume from checkpoint. The most common example of this is if you're >> scheduling an event. curTick is set to the checkpoint tick after >> init() but before startup(), so you should schedule all events in >> startup(). This will likely become more important when we >> parallelize. I could certainly do some asserting when this starts to >> matter. >> >> We really should get this stuff onto the wiki. Steve, if you get a >> skeleton, I can flesh it out. >> >> >> Nate >> ___ >> m5-dev mailing list >> m5-dev@m5sim.org >> http://m5sim.org/mailman/listinfo/m5-dev >> > > I know this isn't a new idea, but this seems like another area where > checkpointing/restoring from a checkpoint would be nice regressions to > have. > > Gabe > ___ > m5-dev mailing list > m5-dev@m5sim.org > http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] changeset in m5: regression: updated memtest-ruby stats
changeset 61f8eb04e96d in /z/repo/m5 details: http://repo.m5sim.org/m5?cmd=changeset;node=61f8eb04e96d description: regression: updated memtest-ruby stats This also includes a change to the default Ruby random seed, which was previously set using the wall clock. It is now set to 1234 so that the stat files don't change for the regression tester. diffstat: 5 files changed, 404 insertions(+), 465 deletions(-) src/mem/ruby/config/defaults.rb|2 tests/quick/50.memtest/ref/alpha/linux/memtest-ruby/ruby.stats | 610 +- tests/quick/50.memtest/ref/alpha/linux/memtest-ruby/simerr | 206 +-- tests/quick/50.memtest/ref/alpha/linux/memtest-ruby/simout | 11 tests/quick/50.memtest/ref/alpha/linux/memtest-ruby/stats.txt | 40 diffs (truncated from 1293 to 300 lines): diff -r 57650468aff1 -r 61f8eb04e96d src/mem/ruby/config/defaults.rb --- a/src/mem/ruby/config/defaults.rb Wed Jul 08 08:40:32 2009 -0500 +++ b/src/mem/ruby/config/defaults.rb Mon Jul 13 14:45:15 2009 -0500 @@ -146,7 +146,7 @@ # Random seed used by the simulation. If set to "rand", the seed # will be set to the current wall clock at libruby # initialization. Otherwise, set this to an integer. - default_param :random_seed, Object, "rand" + default_param :random_seed, Object, 1234 #"rand" # When set to true, the simulation will insert random delays on # message enqueue times. Note that even if this is set to false, diff -r 57650468aff1 -r 61f8eb04e96d tests/quick/50.memtest/ref/alpha/linux/memtest-ruby/ruby.stats --- a/tests/quick/50.memtest/ref/alpha/linux/memtest-ruby/ruby.statsWed Jul 08 08:40:32 2009 -0500 +++ b/tests/quick/50.memtest/ref/alpha/linux/memtest-ruby/ruby.statsMon Jul 13 14:45:15 2009 -0500 @@ -2,7 +2,7 @@ Begin RubySystem Configuration Print RubySystem config: - random_seed: 580633 + random_seed: 1234 randomization: 0 tech_nm: 45 freq_mhz: 3000 @@ -14,7 +14,7 @@ version: 0 buffer_size: 32 dma_sequencer: DMASequencer_0 - number_of_TBEs: 128 + number_of_TBEs: 256 transitions_per_cycle: 32 Directory_Controller config: DirectoryController_0 version: 0 @@ -23,7 +23,7 @@ directory_name: DirectoryMemory_0 memory_controller_name: MemoryControl_0 memory_latency: 158 - number_of_TBEs: 128 + number_of_TBEs: 256 recycle_latency: 10 to_mem_ctrl_latency: 1 transitions_per_cycle: 32 @@ -33,7 +33,7 @@ cache: l1u_0 cache_response_latency: 12 issue_latency: 2 - number_of_TBEs: 128 + number_of_TBEs: 256 sequencer: Sequencer_0 transitions_per_cycle: 32 L1Cache_Controller config: L1CacheController_1 @@ -42,7 +42,7 @@ cache: l1u_1 cache_response_latency: 12 issue_latency: 2 - number_of_TBEs: 128 + number_of_TBEs: 256 sequencer: Sequencer_1 transitions_per_cycle: 32 L1Cache_Controller config: L1CacheController_2 @@ -51,7 +51,7 @@ cache: l1u_2 cache_response_latency: 12 issue_latency: 2 - number_of_TBEs: 128 + number_of_TBEs: 256 sequencer: Sequencer_2 transitions_per_cycle: 32 L1Cache_Controller config: L1CacheController_3 @@ -60,7 +60,7 @@ cache: l1u_3 cache_response_latency: 12 issue_latency: 2 - number_of_TBEs: 128 + number_of_TBEs: 256 sequencer: Sequencer_3 transitions_per_cycle: 32 L1Cache_Controller config: L1CacheController_4 @@ -69,7 +69,7 @@ cache: l1u_4 cache_response_latency: 12 issue_latency: 2 - number_of_TBEs: 128 + number_of_TBEs: 256 sequencer: Sequencer_4 transitions_per_cycle: 32 L1Cache_Controller config: L1CacheController_5 @@ -78,7 +78,7 @@ cache: l1u_5 cache_response_latency: 12 issue_latency: 2 - number_of_TBEs: 128 + number_of_TBEs: 256 sequencer: Sequencer_5 transitions_per_cycle: 32 L1Cache_Controller config: L1CacheController_6 @@ -87,7 +87,7 @@ cache: l1u_6 cache_response_latency: 12 issue_latency: 2 - number_of_TBEs: 128 + number_of_TBEs: 256 sequencer: Sequencer_6 transitions_per_cycle: 32 L1Cache_Controller config: L1CacheController_7 @@ -96,7 +96,7 @@ cache: l1u_7 cache_response_latency: 12 issue_latency: 2 - number_of_TBEs: 128 + number_of_TBEs: 256 sequencer: Sequencer_7 transitions_per_cycle: 32 Cache config: l1u_0 @@ -376,27 +376,27 @@ End RubySystem Configuration Print -Real time: Jul/06/2009 11:20:36 +Real time: Jul/13/2009 11:35:28 Profiler Stats -- -Elapsed_time_in_seconds: 569 -Elapsed_time_in_minutes: 9.48333 -Elapsed_time_in_hours: 0.158056 -Elapsed_time_in_days: 0.00658565 +Elapsed_time_in_seconds: 2022 +Elapsed_time_in_minutes: 33.7 +Elapsed_time_in_hours: 0.561667 +Elapsed_time_in_days: 0.0234028 -Virtual_time_in_seconds: 568.45 -Virtual_time_in_minutes: 9.47417 -Virtual_time_in_hours: 0.157903 -Virtual_time_in_days:0.157903 +Virtual_time_in_seconds: 2021.58 +Virtual_time_in_minutes: 33.693 +Virtual_ti
[m5-dev] changeset in m5: merge
changeset 99ca47c2130b in /z/repo/m5 details: http://repo.m5sim.org/m5?cmd=changeset;node=99ca47c2130b description: merge diffstat: 164 files changed, 4889 insertions(+), 9219 deletions(-) src/arch/SConscript |3 src/arch/alpha/SConscript |6 src/arch/alpha/ev5.cc | 16 src/arch/alpha/ev5.hh |4 src/arch/alpha/floatregfile.cc | 57 src/arch/alpha/floatregfile.hh | 119 - src/arch/alpha/intregfile.cc | 74 src/arch/alpha/intregfile.hh | 73 src/arch/alpha/isa.cc | 150 + src/arch/alpha/isa.hh | 117 + src/arch/alpha/isa/main.isa |5 src/arch/alpha/isa_traits.hh | 42 src/arch/alpha/locked_mem.hh |2 src/arch/alpha/miscregfile.cc | 158 -- src/arch/alpha/miscregfile.hh | 126 - src/arch/alpha/mmaped_ipr.hh |3 src/arch/alpha/regfile.cc | 100 - src/arch/alpha/regfile.hh | 230 -- src/arch/alpha/registers.hh | 109 + src/arch/alpha/regredir.cc | 52 src/arch/alpha/regredir.hh | 43 src/arch/alpha/remote_gdb.cc |1 src/arch/alpha/types.hh | 16 src/arch/alpha/utility.cc | 35 src/arch/alpha/utility.hh | 10 src/arch/arm/SConscript |1 src/arch/arm/faults.cc |2 src/arch/arm/insts/macromem.hh | 42 src/arch/arm/insts/mem.cc | 19 src/arch/arm/insts/mem.hh | 91 - src/arch/arm/insts/pred_inst.cc | 12 src/arch/arm/insts/pred_inst.hh | 116 - src/arch/arm/insts/static_inst.cc | 89 - src/arch/arm/insts/static_inst.hh |2 src/arch/arm/isa.hh | 106 + src/arch/arm/isa/decoder.isa | 294 --- src/arch/arm/isa/formats/macromem.isa | 237 ++- src/arch/arm/isa/formats/mem.isa | 291 +-- src/arch/arm/isa/formats/util.isa | 96 - src/arch/arm/isa/operands.isa | 51 src/arch/arm/isa_traits.hh | 44 src/arch/arm/regfile.hh | 36 src/arch/arm/regfile/float_regfile.hh | 181 -- src/arch/arm/regfile/int_regfile.hh | 118 - src/arch/arm/regfile/misc_regfile.hh | 84 - src/arch/arm/regfile/regfile.cc | 86 - src/arch/arm/regfile/regfile.hh | 206 -- src/arch/arm/registers.hh | 150 + src/arch/arm/types.hh | 20 src/arch/arm/utility.hh | 12 src/arch/isa_parser.py
[m5-dev] Cron /z/m5/regression/do-regression quick
* build/ARM_SE/tests/fast/quick/00.hello/arm/linux/simple-atomic passed. * build/X86_SE/tests/fast/quick/00.hello/x86/linux/simple-timing-ruby passed. * build/X86_SE/tests/fast/quick/00.hello/x86/linux/simple-atomic passed. * build/X86_SE/tests/fast/quick/00.hello/x86/linux/simple-atomic-ruby passed. * build/X86_SE/tests/fast/quick/00.hello/x86/linux/simple-timing passed. * build/SPARC_SE/tests/fast/quick/00.hello/sparc/linux/simple-atomic passed. * build/SPARC_SE/tests/fast/quick/00.hello/sparc/linux/simple-timing passed. * build/SPARC_SE/tests/fast/quick/40.m5threads-test-atomic/sparc/linux/simple-timing-mp passed. * build/SPARC_SE/tests/fast/quick/02.insttest/sparc/linux/simple-timing passed. * build/SPARC_SE/tests/fast/quick/40.m5threads-test-atomic/sparc/linux/simple-atomic-mp-ruby passed. * build/SPARC_SE/tests/fast/quick/00.hello/sparc/linux/simple-atomic-ruby passed. * build/SPARC_SE/tests/fast/quick/00.hello/sparc/linux/simple-timing-ruby passed. * build/SPARC_SE/tests/fast/quick/02.insttest/sparc/linux/o3-timing passed. * build/SPARC_SE/tests/fast/quick/40.m5threads-test-atomic/sparc/linux/simple-atomic-mp passed. * build/SPARC_SE/tests/fast/quick/02.insttest/sparc/linux/simple-atomic passed. * build/SPARC_SE/tests/fast/quick/40.m5threads-test-atomic/sparc/linux/o3-timing-mp passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-timing passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-timing passed. * build/ALPHA_SE/tests/fast/quick/01.hello-2T-smt/alpha/linux/o3-timing passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-atomic-ruby passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-atomic passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/o3-timing passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/inorder-timing passed. * build/ALPHA_SE/tests/fast/quick/20.eio-short/alpha/eio/simple-timing passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby passed. * build/ALPHA_SE/tests/fast/quick/30.eio-mp/alpha/eio/simple-timing-mp passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-atomic-ruby passed. * build/ALPHA_SE/tests/fast/quick/30.eio-mp/alpha/eio/simple-atomic-mp passed. * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-atomic passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-atomic passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/o3-timing passed. * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-atomic-ruby passed. * build/ALPHA_SE/tests/fast/quick/20.eio-short/alpha/eio/simple-atomic passed. * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/o3-timing passed. * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-timing passed. * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/inorder-timing passed. * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-timing-ruby passed. * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-atomic passed. * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-atomic-dual passed. * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-timing passed. * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-timing-dual passed. * build/ALPHA_FS/tests/fast/quick/80.netperf-stream/alpha/linux/twosys-tsunami-simple-atomic passed. * build/ALPHA_SE/tests/fast/quick/50.memtest/alpha/linux/memtest passed. * build/ALPHA_SE/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby FAILED! See /z/m5/regression/regress-2009-07-13-03:00:02 for details. ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
