Yeah, I kinda though that too, more along the lines that other OpenSparc binaries are dependent somehow on the hypervisor binary and should also be recompiled. So, I did post to their forum, but they are not responding. So, I will look through OpenSparc and see if maybe they are hardcoding this.
On Tue, Mar 10, 2009 at 1:30 PM, Gabriel Michael Black < gbl...@eecs.umich.edu> wrote: > I was thinking about that the other day, and maybe OpenSparc is > configuring the first thread of each core? Those could be numerically > 4 apart, one per thread, which I believe is what you said is happening. > > Gabe > > Quoting Polina Dudnik <pdud...@gmail.com>: > > > So, just to keep everyone posted: I did what Gabe suggests and returned > > whenever a thread is unallocated and got the same seg fault I was getting > in > > stable release where the processor numbers had to be swizzled. Meanwhile, > in > > the stable release where I did swizzle the numbers I am getting an > assertion > > error which tells me that I am seeing an interrupt number that is out of > > range. > > > > In general I think it is worthwhile fixing the cpu number assignment at > the > > root otherwise I will keep seeing seg faults that require swizzling. So, > I > > am trying to understand in OpenSparc why changing the cpu numbers in the > > hypervisor doesn't fix the problem. > > > > Polina > > > > On Fri, Mar 6, 2009 at 11:24 AM, Polina Dudnik <pdud...@gmail.com> > wrote: > > > >> > >> > >> On Thu, Mar 5, 2009 at 5:10 PM, Gabriel Michael Black < > >> gbl...@eecs.umich.edu> wrote: > >> > >>> The change is simple enough that I'll just describe it. This deals > >>> solely with the simple CPU, so if your trying to use O3, for example, > >>> it won't help you directly. The code here: > >>> http://repo.m5sim.org/m5/file/886da6fa6d4a/src/cpu/simple/base.cc#l307 > >>> should return if the thread is suspended -or- unallocated. After you > >>> change that, I think you'll also run into an assert in the CPU. I just > >>> got rid of the assert and haven't had any problems, but that might not > >>> be the right thing to do. > >>> > >>> Gabe > >> > >> > >> I looked at l307 and I don't think it should return if the thread is > >> suspended. It should get activated if the thread is suspended, isn't > that > >> right or am I missing something? > >> > >> Polina > >> > >> > >>> > >>> > >>> Quoting Polina Dudnik <pdud...@gmail.com>: > >>> > >>> > Oh, I see. Do you think you can distribute the partial patch you > have? > >>> > > >>> > Thank you. > >>> > > >>> > Polina > >>> > > >>> > On Thu, Mar 5, 2009 at 4:48 PM, Gabriel Michael Black < > >>> gbl...@eecs.umich.edu > >>> >> wrote: > >>> > > >>> >> Quoting Polina Dudnik <pdud...@gmail.com>: > >>> >> > >>> >> > On Thu, Mar 5, 2009 at 3:38 PM, Gabriel Michael Black < > >>> >> gbl...@eecs.umich.edu > >>> >> >> wrote: > >>> >> > > >>> >> >> There's actually a bug in the CPU wakeup code which prevents any > CPU > >>> >> >> that isn't activated and then suspended, like SPARCs APs which > are > >>> >> >> suspended directly, from waking up on interrupts, etc. I have a > >>> >> >> partial fix which I've been using to work around the problem, but > we > >>> >> >> need to come up with a full solution. I don't know if this is > what > >>> the > >>> >> >> problem is, but it sounds like it could be. > >>> >> >> > >>> >> >> Gabe > >>> >> > > >>> >> > > >>> >> > Are you talking about the seg fault in m5-stable that I get? Or > the > >>> CPU > >>> >> ids? > >>> >> > > >>> >> > Polina > >>> >> > > >>> >> > > >>> >> > >>> >> I was talking about the hang Ali described. If the BP is waiting for > >>> >> an AP to tell it it's alive and the AP never wakes up, the system > will > >>> >> likely hang. I ran into that problem in X86_FS. > >>> >> > >>> >> 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 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
