Hi Nilay,
Does a system with multiple o3 cpus correct start up with this change? Is there something that kicks it from Idle->Running? Ali On 06.06.2013 06:58, Andreas Hansson wrote: > Hi Nilay, > > Thanks for the update. Another day to be amazed that things worked. > > Andreas > > On 06/06/2013 12:54, "Nilay Vaish" <[email protected]> wrote: > >> Actually the problem, it turned out, is with the o3 cpu. The fetch stage, when it overtakes from another cpu, initializes its status variable to Running. When an o3 cpu is about to switch to another cpu, the fetch stage checks that its status should be Idle. Now suppose there are two processors in the system. The operating system has just started and it is running on cpu0. Then, cpu1 would not be actually doing anything. When trying to switch to another cpu, cpu1 gets stuck because there is nothing going on that will move it from Running to Idle. Making the following change allows the simulation to proceed smoothly. diff -r 8873fd449657 -r 02285e0961a1 src/cpu/o3/fetch_impl.hh --- a/src/cpu/o3/fetch_impl.hh Wed Jun 05 22:34:02 2013 -0500 +++ b/src/cpu/o3/fetch_impl.hh Wed Jun 05 23:32:09 2013 -0500 @@ -317,7 +317,8 @@ // Setup PC and nextPC with initial state. for (ThreadID tid = 0; tid < numThreads; tid++) { - fetchStatus[tid] = Running; + //fetchStatus[tid] = Running; + fetchStatus[tid] = Idle; pc[tid] = cpu->pcState(tid); fetchOffset[tid] = 0; macroop[tid] = NULL; -- Nilay On Thu, 6 Jun 2013, Andreas Hansson wrote: >> >>> Hi Nilay, I'll have a look at the DRAM controller. As you mention, the switching regressions do not seem to have any issues. Did you get any further in isolating the problem? Thanks, Andreas On 06/06/2013 05:01, "Nilay Vaish" <[email protected]> wrote: >>> >>>> No, this is not the bug we are looking for. I just figured how the drain functionality works. -- Nilay On Wed, 5 Jun 2013, Joel Hestness wrote: >>>> >>>>> Hey Nilay, I haven't experienced this bug, but it may be the same one that Mahshid (cc'd: [email protected]) is experiencing with her trouble restoring a checkpoint with a large-scale CMP (in this thread: http://www.mail-archive.com/[email protected]/msg07639.html [2]). If she happens to still have that checkpoint, she might be able to test whether her system sees the same draining bug. Joel On Wed, Jun 5, 2013 at 5:51 PM, Nilay Vaish <[email protected]> wrote: >>>>> >>>>>> I am trying to debug some issue with switching of cpus in a multiprocessor system. While trying to drain the system, there is a call to simulate() ins function _drain() that seemingly gets stuck. To me it seems that it should return when the main event queue becomes empty. But simple DRAM keeps on posting its refresh event. It seems that once the DRAM has moved to drained / draining state, it should not post the refresh event. Can some one confirm that this is a bug in Simple DRAM? Given that there are switch cpu regressions that we run every week, it is hard to believe that Simple DRAM has a bug in its drain functionality. But I have not been able to come up with an alternate explanation either. Thanks Nilay ______________________________**_________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/ [1]**listinfo/gem5-dev<http://m5sim.org/mailman/ [1] li stinfo/gem5-dev> >>>>> -- Joel Hestness PhD Student, Computer Architecture Dept. of Computer Science, University of Wisconsin - Madison http://pages.cs.wisc.edu/~hestness/ [3] _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev [4] >>>> _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev [4] >>> -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev [4] >> _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev [4] > > -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. > > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev [4] Links: ------ [1] http://m5sim.org/mailman/ [2] http://www.mail-archive.com/[email protected]/msg07639.html [3] http://pages.cs.wisc.edu/~hestness/ [4] http://m5sim.org/mailman/listinfo/gem5-dev _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
