OK, I tracked it down a little further... the problem with having O3 initialize threads to Unallocated is in the activate() method in cpu/o3/thread_context_impl.hh, where the CPU checks to make sure that there are enough resources to activate a thread if it's in Unallocated state (as opposed to Suspended state, where it assumes those resources are already allocated). There must be a bug in that code since even if the very first thread is in Unallocated it still doesn't start up properly. However there's potentially a more general problem if the CPU doesn't reserve the physical registers for a thread from the very beginning. I'll keep probing as time permits...
Steve On Mon, Jun 23, 2008 at 8:41 PM, Steve Reinhardt <[EMAIL PROTECTED]> wrote: > It's a bug in M5. The SE threading code expects the "idle" contexts > to be in state Unallocated (see nxm_thread_createFunc in > src/kern/tru64/tru64.hh), which is what SimpleCPU does. However O3 > initializes unused threads to Suspended (see > src/cpu/o3/alpha/cpu_impl.hh). Unfortunately just changing the O3 > initialization to Suspended caused other problems which I haven't > figured out yet. > > Steve > > On Mon, Jun 23, 2008 at 2:47 PM, Sujay Phadke <[EMAIL PROTECTED]> wrote: >> Well I wanted to run the O3 (n>1) for testing wattch. Is it wrong to run it >> in detailed mode directly w/o using any switching? >> If so, can you give me an example file and command line which does switching >> for say Splash2? >> >> thanks, >> Sujay >> >> ----- Original Message ----- >> From: "Ali Saidi" <[EMAIL PROTECTED]> >> To: "M5 users mailing list" <[email protected]> >> Sent: Monday, June 23, 2008 5:39 PM >> Subject: Re: [m5-users] error running O3 directly with more than 1 cpu >> >> >>> >>> On Jun 23, 2008, at 1:23 PM, Sujay Phadke wrote: >>> >>>> Hello, >>>> If I try to run O3 in SE mode directly, without using any >>>> fastforwarding, it gives me the error: >>>> >>>> build/ALPHA_SE/m5.opt configs/splash2/runsplash.py -d -n4 -b >>>> OceanContig >>>> >>>> warn: Increasing stack size by one page. >>>> warn: ignoring syscall sigprocmask(3, 18446744073709551615, ...) >>>> warn: ignoring syscall sigprocmask(3, 0, ...) >>>> warn: ignoring syscall sigaction(8, 4831387552, ...) >>>> warn: ignoring syscall sigaction(11, 4831387552, ...) >>>> warn: ignoring syscall sigaction(10, 4831387552, ...) >>>> warn: ignoring syscall sigaction(4, 4831387552, ...) >>>> warn: ignoring syscall sigaction(7, 4831387552, ...) >>>> warn: ignoring syscall sigaction(6, 4831387552, ...) >>>> warn: ignoring syscall sigaction(12, 4831387552, ...) >>>> warn: ignoring syscall sigaction(5, 4831387552, ...) >>>> warn: ignoring syscall sigaction(13, 4831387552, ...) >>>> nxm_thread_create: no idle contexts available. >>>> Program aborted at cycle 378945000 >>>> It works fine of numcpus (-n) = 1, or if I use atomic or timing >>>> mode. The statement >>>> >>>> thread->setStatus(ThreadContext::Unallocated); >>>> >>>> appears in src/cpu/simple/base.cc and src/cpu/o3/ >>>> thread_context_impl.hh. >>>> >>> The statement and the context the statement is in are two different >>> things. From a cursory look of the O3CPU, it appears as though the >>> state of the thread context is never initialized when the thread >>> context is created, and the places where it is set to unallocated are >>> for switching CPUs. Initializing it to Unallocated should solve the >>> problem. >>> >>> Are you planning on running a detailed CPU for the entirety of the >>> benchmark? >>> >>> Ali >>> >>> _______________________________________________ >>> 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
