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<s...@cse.usf.edu> wrote: > Thanks, Gabe. My comments are embedded in your reply. > > On Mon, Jul 13, 2009 at 8:57 PM, Gabriel Michael Black > <gbl...@eecs.umich.edu> 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 <s...@cse.usf.edu>: >> >>> Thanks for your replies. >>> >>> All I did were the following (from <m5-root-dir>): >>> >>> 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 <ste...@gmail.com> >>> 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 <jameswan...@yahoo.com> >>>> 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<s...@cse.usf.edu> >>>>> 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): >>>>> > </fast/quick/01.hello-2T-smt/sparc/linux/o3-timing$ more simout >>>>> > 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 1000000000000 ticks per second >>>>> > numThreads: 2 >>>>> > numIntRegs: 169 >>>>> > numFloatRegs: 64 >>>>> > info: Entering event queue @ 0. Starting simulation... >>>>> > Exiting @ tick 9223372036854775807 because simulate() limit reached >>>>> > >>>>> > While my simerr is this: >>>>> > </fast/quick/01.hello-2T-smt/sparc/linux/o3-timing$ more simerr >>>>> > warn: Sockets disabled, not accepting gdb connections >>>>> > For more information see: http://www.m5sim.org/warn/d946bea6 >>>>> > >>>>> > What am I doing wrong here? >>>>> > >>>>> > regards, >>>>> > Soumyaroop. >>>>> > >>>>> > -- >>>>> > Soumyaroop Roy >>>>> > Ph.D. Candidate >>>>> > Department of Computer Science and Engineering >>>>> > University of South Florida, Tampa >>>>> > http://www.csee.usf.edu/~sroy <http://www.csee.usf.edu/%7Esroy> >>>>> > _______________________________________________ >>>>> > m5-users mailing list >>>>> > m5-us...@m5sim.org >>>>> > http://m5sim.org/cgi-bin/mailman/listinfo/m5-users >>>>> > >>>>> >>>>> >>>>> >>>>> -- >>>>> Regards >>>>> James Wang >>>>> _______________________________________________ >>>>> m5-users mailing list >>>>> m5-us...@m5sim.org >>>>> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users >>>>> >>>> >>>> >>>> _______________________________________________ >>>> m5-users mailing list >>>> m5-us...@m5sim.org >>>> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users >>>> >>> >>> >>> >>> -- >>> Soumyaroop Roy >>> Ph.D. Candidate >>> Department of Computer Science and Engineering >>> University of South Florida, Tampa >>> http://www.csee.usf.edu/~sroy >>> >> >> > > > > -- > Soumyaroop Roy > Ph.D. Candidate > Department of Computer Science and Engineering > University of South Florida, Tampa > http://www.csee.usf.edu/~sroy > > _______________________________________________ > m5-users mailing list > m5-us...@m5sim.org > http://m5sim.org/cgi-bin/mailman/listinfo/m5-users > -- - Korey _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
